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ABSTRACT 

The Joint Fleet Telecommunications Operations Center (JFTOC) acts, on behalf 
of the Naval Computer and Telecommunications Command, as the fleet’s “one-stop 
shop” for information services. Effective fault management is vital to ensuring reliable 
network service. Currently, however, the JFTOC employs a Fault Management System 
(FMS) that consists primarily of manual processes and non-networked resources. Users 
require a system that provides a centralized and accessible source of near-real time fault 
management information. 

This thesis uses the methodology of the Department of Defense (DoD) Technical 
Architecture Framework for iageanenion Management (TAFIM). TAFIM outlines a 
Structured approach for migrating legacy systems to a open systems, standards-based 
target architecture. 

Through application of the TAFIM process, a target FMS architecture, termed 
HelpDesk On-Line Information System (HOLIS), 1s developed. HOLIS includes: the 
existing NCTAMS classified local area network and SIPRNet infrastructure; network 
operating system, office automation, e-mail and database software from the interim Navy 
Automated Information System Standards list: and commercial off-the-shelf help desk 
software. Four migration paths are outlined. and one is selected as the best option for 


moving from the baseline system to the target FMS. 
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I. INTRODUCTION 


A. BACKGROUND 

It is just before dawn, and the radiomen on USS Blue Ridge, underway in the 
Eastern Pacific, are unable to activate the video teleconference circuit (VTC) for 
COMTHIRDFLT’s morning meeting with his commanders ashore. After numerous 
unsuccessful attempts, the watch supervisor uses the ship’s Secret Internet Protocol 
Router Network (SIPRNet) connectivity to access the Naval Computer and 
Telecommunications Area Master Station Eastern Pacific (NCTAMS EASTPAC) Joint 
Fleet Telecommunications Operations Center (JFTOC) homepage. Here, he finds the 
link to the Helpdesk On-Line Information System (HOLIS) and electronically fills out a 
trouble ticket reporting the problem symptoms and the actions taken to date. JFTOC 
personnel read the trouble ticket and immediately commence trouble shooting. As 
restoral efforts progress, Blue Ridge and PRNOC personnel log in for near real-time 
updates of troubleshooting events. 

When the NCTAMS EASTPAC Commanding Officer (CO), Communications 
Officer (Commo) and other senior leaders arrive at work. they access HOLIS using their 
desktop PCs and review all events from the past 24 hours. Commo views the message 
traffic and reports about the Blue Ridge VTC outage with concern. After bnefing her 
staff to give this outage particular attention, she leaves the building for a meeting down 
island. She returns two hours later to learn that the COMTHIRDFLT Commo. CDR 
Jones, is on the phone. While speaking to CDR Jones, she simultaneously brings up the 


Blue Ridge trouble ticket on her computer. She is able to quickly review all 


troubleshooting actions that have taken place on Blue Ridge and at NCTAMS during the 
past few hours. She and CDR Jones discuss the actions that have been taken to date and 
make a joint entry into the trouble ticket directing additional actions. This entry is 
received by the JFTOC Joint Watch Officer (JWO) who takes immediate action. Within 
the hour, the fault is diagnosed and corrected. 

The Fault Management System (FMS) described here does not yet exist. 
However, in order to meet the needs of the 21* century Navy, the JFTOC, the central 
point of network management in each Naval Computer and Telecommunications 
Command (NCTC) region, requires an effective FMS. An information system that 
provides troubleshooting, coordination, and fault resolution information to both providers 


and users of NCTC information services. 


B. OBJECTIVE 

The objective of this study is to develop a FMS Target Architecture and a 
migration path for achieving this goal state. This Target Architecture will improve the 
quality of NCTC information services by minimizing outage lengths; reducing time spent 
coordinating, documenting, and reporting troubleshooting and restoral efforts; and 


enabling performance trend analysis. 


©; APPROACH 

This study utilizes the Structured Technical Architecture Framework for 
Information Management (TAFIM) Process which is a variation of the model presented 
in the DOD TAFIM. The DOD TAFIM is an eight-volume document published by the 


Defense Information Systems Agency (DISA) Center for Standards. It defines an open 


systems, standards-based architecture for DOD information systems. Volume 4, DOD 
Standards-Based Architecture (SBA) Planning Process, outlines a methodology for 
migrating legacy systems to target systems within the standards-based, TAFIM 
architecture, Fault Management System (FMS) Architecture. 

The SBA Planning Process was modified for student use by an NPS Information 
Technology Management (ITM) Professor and termed the Structured TAFIM process. 
Essentially, it adds one step (Step Two: Define System Problem) to emphasize the 
importance of formally defining the system problem being addressed. Figure 1.1 shows 
the Structured TAFIM Process. Table 1.1 provides the purpose of each step. [Ref. 21:pp. 


1-3] 


STRUCTURED TAFIM PROCESS 


Assess 
Baseline 
sterp 


4 
Determine 
Target 
ste 





andidate : 


Figure 1.1. Structured TAFIM Process. [Ref. 21] 


Table 1.1. Purpose of Structured TAFIM Process Steps [Ref. 4: pp. 1-4] 





PURPOSE 


Develop an initial plan for engineering & managing a system over time. 
Step 2 | Structure the system problem so all participants in the Structured TAFIM 
Process clearly understand the problem being solved. 
Determine the character and state of the current system. 
Determine the character and state of the desired (goal) system. 
Step 5 | Develop several feasible paths, including plans, hardware, software, 
technical and managerial support, etc. 
Use criterion to select the best migration path, given the risk and uncertainty 
present. 


Implement the selected system migration path. 


| Step 8 | Revise the migration path over time to adapt to the realties of technological 


| change, available budgets, and new and different requirements. | 


This study presents a full illustration of steps one through six of the Structured 





il 













TAFIM Process. Issues concerning implementation and maintenance, steps seven and 
eight, are incorporated into the previous steps, primarily the Chapter covering migration 


candidates development. 


D. STUDY ORGANIZATION 

While oriented towards the Navy telecommunications professional, this thesis 
provides ample background and description to enable understanding by anyone with a 
basic information technology background. A short description of each chapter of this 
thesis 1s provided below: 

e Chapter II - Establishing the Problem Framework - Maps the role of the JFTOC 


to Joint and Navy C4I doctrine and policy, and discusses the JFTOC mission, 
functions, and organizational relationships. 


e Chapter II] - DEFINING THE SYSTEM PROBLEM - Provides a user 
assessment of the current system, overview of help desk technology, and formal 
problem statement. 


e Chapter IV - ASSESSING THE BASELINE SYSTEM - Examines the policies, 
processes, outputs, and physical characteristics that define the baseline system. 


e Chapter V - DETERMINING THE TARGET SYSTEM - Presents a goal 
architecture overview; identifies problem formulation constraints; examines 
target system processes and network architecture; and discusses the required 
capabilities of a help desk application in the target system. 


e Chapter VI - DEVELOPING THE MIGRATION PATH CANDIDATES - 
Creates several feasible paths for moving from the baseline system to the target 
architecture; this includes timeline and cost breakdowns for each migration path 
option. 


e Chapter VII - SELECTING A MIGRATION PATH - Reviews path selection 
criteria; calculates discounted present value of each migration path option; and 
explores the fiscal impact of phase scheduling. 


e Chapter VIII - RECOMMENDATION AND CONCLUSIONS - Provides 
recommendations, areas requiring further study, and conclusions. 





ll. ESTABLISHING THE PROBLEM FRAMEWORK 


A. INTRODUCTION 

The role of the JFTOC continues to grow as telecommunications management 
evolves from the stovepipe, radio frequency (RF) links of the past to the fully integrated, 
wide-area tactical networks of the future. This chapter illustrates step one of the 
Structured TAFIM Process by establishing the framework within which the JFTOC’s role 
is defined. Specifically, the relationship between JFTOC and Navy C4I doctrine is 
explored regarding the JFTOC’s role in achieving the vision of NCTC, and in turn, the 
vision of the Navy. Finally, JFTOC’s mission, functions, and organizational 


relationships are discussed. 


B. DOCTRINE AND POLICY 

1. Joint Pub 6-0 

Joint Pub 6-0, Doctrine for Command, Control, Communications, and Computer 
(C4) Systems Support to Joint Operations articulates the C4 principles required to 
achieve “information superiority’; the key to the “full spectrum dominance” required by 
Joint Vision 2010 (JV 2010). (Ref. 1] Joint Pub 6-0 states, “The fundamental objective 
of C4 systems is to get the critical and relevant information to the nght place in time to 
allow forces to seize on opportunity and mect the objectives across the range of military 
operations.” [Ref. 2:p. 1-1] This statement makes it clear that time ts a critical factor in 


achieving C4 system objectives. 


2 Information for the 21 Century (IT-21) 

IT-21 is a strategy for achieving the goals of JV 2010. It is a joint Commander- 
in-Chief, Pacific Fleet (CINCPACFLT)/Commander-in-Chief, Atlantic Fleet 
(CINCLANTFLT) initiative that addresses several critical, short-term requirements. 
Central among these requirements is the need to implement a network infrastructure at 
the local, metropolitan, and global levels to enable message communication between all 
U.S. Forces and allies upon the inactivation of the current DOD messaging system, 
Automatic Digital Information Network (AUTODIN), by December 1999. [Ref. 3] 

IT-21, however, addresses more than just messaging, its architecture, 
infrastructure and applications will enable “voice, video, and data transmissions from a 
single desktop PC, allowing the warfighter to exchange information that is classified or 
unclassified, tactical or nontactical.” [Ref. 4:p. 52] Defense Information System Network 
(DISN) Internet Protocol (IP) networks will be employed to form a wide-area, tactical 
network. These networks include: Non-secure Internet Protocol Router Network 
(NIPRNet) for Unclassified information; SIPRNet for Confidential and Secret 
information; and Joint Worldwide Intelligence Communications System (JWICS) for 
Sensitive Compartmented Information (SCI). [Ref. 5] 

Using the guidance set forth in the DOD Joint Technical Architecture (JTA) and 
Defense Information Infrastructure Common Operating Environment (DI] COE), \T-21 
establishes minimum Navy Automated Information System (AIS) standards. The policy 
requires replacement of all non-standard Network Operating System (NOS) and 
electronic mail (e-mail) products no later than December 1999. Tables 2.1, 2.2, 2.3 and 


2.4 display 1T-2! minimum standards for Networks (includes: Local Area Network 


(LAN) and Metropolitan Area Network (MAN), Software, PC and File Servers. The 
standards will be updated on a periodic basis based on technology changes and market 
trends. [Ref. 3] Standards include: 


Table 2.1. IT-21 Minimum Network Standards. [Ref. 3] 


NETWORK TYPE STANDARDS 


LAN: 


/MAN At least OC-3 (155 Mbps) capable. 


Afloat/Ashore ATM Fiber Backbone, 100 Mbps (Fast Ethernet) to PC. | 





Table 2.2. IT-21 Software Standards. [Ref. 3] 


STANDARD 
Microsoft (MS) NT Server 4.0 
MS NT 4.0/5.0 Workstation 
MS Office 97 Professional 


| E-mail | MS Exchange 5.0 


| Database Relational database that supports WWW technology IAW DII 
| a COE (e.g., Oracle, Sybase, MS SQL Server, MS Access, etc.) 









Table 2.3. IT-21 Workstation Standards. [Ref. 3] 

















[COMPONENT | MINIMUMSTANDARD | 
(PU SS~*Y R00 Mz Pentium Pro SCS 
[RAM__———S—S—SCSCS MBE SSSCSC~SCSCSY 
Mulit-Media Components PCI Video with 2 MB RAM 
Sounblaster Compatible Audio Card 






To achieve the goal of all commands being voice, video, and data 


transmission capable from/to a single, desktop PC. including e-mail exchange capabilities 


for all ships by the year 2000, IT-21 establishes seven “absolute precepts”. Figure 2.1 
displays these principles. 


Table 2.4. IT-21 Server Standards. [Ref. 3] 












| COMPONENT NETWORK DIRECTORY APPLICATION/FILE | 
| SERVER STANDARDS SERVER STANDARDS 
Dual 166 MHz Pentium Pro 


RAM 256 MB RAM same 
i 512K Secondary Cache 


| Caching Controllers | 2 DPT SCSI UI (SmartCache 4) —_—‘| same 


PCI Video PCI Video with 2MB RAM 


NIC (2) Cabletron CPU Compatible same 
ATM NIC 








‘SEVEN HABITS OF A HIGHLY EFFECTIVE | 
FLEET INFORMATION TECHNOLOGY 
SYSTEM 










If the boss doesn't use it, don't buy it. 
We must integrate the tactical and non-tactical. 

e We must stay with industry. 

We must drive everything to a single PC. 

We must use commercial off-the-shelf products (COTS). 
We must have seamless transition from shore to sea. 

e We cannot allow stovepipes to develop within our C’l 
architecture. 


Figure 2.1. IT-21 Principles. [Ref. 4, pp. 52-53} 


a NCTC Vision for the 21" Century 
NCTC Vision for the 21st Century articulates the NAVCOMTELCOM strategic 
vision for the next century. In addition, it outlines a primary goal, five secondary goals, 


and numerous challenges that will be part of achieving each goal. Expanding the role of 


the JFTOC is one of the challenges described. Figure 2.2 shows the JFTOC’s 
relationship to the NCTC strategic vision. [Ref. 31:p. 2-4] 
e Vision: “To be the primary manager of electronic information transfer 
for the warfighters of the sea services.” 
e Primary Goal: “To efficiently manage the flow of information so that 
the Fleet Commanders can unite the warfighters at sea and ashore into a 


cohesive and effective force.” 


e Goal #5: “We will meet the communication needs of the Fleet CINCs 
throughout the electromagnetic spectrum.” 


e Challenge: “Expanding the role of the Joint Fleet 
Telecommunications Operations Center (JF TOC) to include the full 
range of network operations management...” 





Figure 2.2. Relationship of JFTOC to NCTC’s Strategic Vision. [Ref. 31:p. 
3-4] 


4. NCTC CNMP 

The NCTC CNMP contains the doctrine for implementing the command’s 
strategic vision for the 21° century. It provides a Corporate Network Management 
Structure for the claimancy which includes headquarters, region, area, and base levels. 
The CNMP outlines the mission, objectives, functions, and responsibilties of each level. 
Figure 2.3 shows the Corporate Network Management Structure and the relationship 
among levels. [Ref. 29:p.7] At the Headquarters level NAVCOMTELCOM in 
Washington D.C. is an echelon 2 command that reports directly to the Chief of Naval 
Operations. [Ref. 30:p. 3-1] Three NCTAMS located in Wahiawa, Hawaii: Norfolk, 
Virginia; and Naples. Italy, each with a JFTOC. provide network management at the 
Regional level. Within each region. areas are managed by Integrated Management 


Support Centers (IMSCs) (shown in Figure 2.4 as a single IMSC for simplification). An 


Area IMSC corresponds to a current Naval Computer and Telecommunications Stations 
(NCTS). The bases or installations within the areas have IMSCs which provide 


telecommunications management services. [Ref. 29:pp. 20-21] 





Figure 2.3. Corporate Network Management Structure. [Ref. 
29:p.7| 


>: JFTOC Relationship to Doctrine and Policy 

Figure 2.4 shows the relationship between the role of the JFTOC and Navy 
doctrine and policy just discussed. As the strategic vision of the Armed Forces, JV 2010 
describes the organization that DOD aspires to be in the near future, and JP 6-0 provides 
doctrine based upon that vision. Although not discussed in detail in this study, the J7A 
and D/I COE also identifies cntical doctrine; common standards for IT and C4I systems. 
The goals of JI’ 20/0 are realized through enactment of stategies such as /7-2/. Using 
the course charted by JV 2010, NCTC Vision for the 21" Century establishes a strategic 


vision for the NAVCOMTELCOM claimancy. The CNMP, as a doctrinal document, 


plays a role analogous to JP 6-0. A strategy, central to achieving NCTC’s vision, is, 
“Meeting the communication needs of the FLTCINCs throughout the electromagnetic 
spectrum.” [Ref. 31:p. 3] The CVMP suggests that a task necessary for that strategy is to 


expand the network operations management services of JFTOC. [Ref. 31:p. 4] 
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Figure 2.4. Relationship Between JFTOC and DOD Doctrine. 






Gc: NCTAMS OVERVIEW 

NAVCOMTELCOM is organized for operational and administrative functions 
into three regions: Pacific. Atlantic and Mediterranean. These regions correspond 
geographically with the areas of responsibility (AOR) of the fleet commanders. Each 
region ts directed by a NCTAMS. [Ref. 3l:p. 4-1] The two major telecommunications 


functions performed by a NCTAMS are: [Ref. 31:p. 6-1] 


e Operational direction of region-wide telecommunications resources. 
e Operational and maintenance of assigned telecommunications resources. 
l. NCTAMS Organizational Relationships: 


A. With NCTC 


NCTAMS are Echelon 3 commands which report directly to 
NAVCOMTELCOM for the operation, maintenance, and administration of the 
telecommunications facilities within their regions. This region-wide operational 
authority is delegated by COMNAVCOMTELCOM to Commanding Officers (COs) of 
NCTAMS. [Ref. 30:p. 5-3] 

b. With FLTCINCs 

FLTCINCs exercise direction and control of direct fleet support 
telecommunications functions managed, performed, or facilitated by the NCTAMS. As 
such, NCTAMS COs are under the operational control of the FLTCINC. [Ref. 30:p. 5-3] 

C. With NCTS 

As delegated by COMNAVCOMTELCOM, each NCTAMS provides 
operational! direction to the NCTSs within its region. [Ref. 30:p. 5-3] Type Commander 
authority for NCTSs, however, is 1s not delegated to the NCTAMS. [Ref. 30:p. 3-2] 

pap NCTAMS Organizational Structure 

Essentially, all three NCTAMS share a common organizational structure with 
Working Capital Fund (WCF) departments as the only variant. The typical NCTAMS 
departmental organization includes: [Ref. 37] 

e NI: Management Resources 


e N2: Base Level Communications 


e N3: Communications Department 

e N4: Facilities 

e N5: Regional Plans 

e N6: Electronic Maintenance 

e N7: Supply and Fiscal 

e N8/N9: Technical Services (WCF Department(s)) 

ay Communications Department Organizational Structure 

The Communications Department, N3, is responsible for the operational direction 
of the Naval Computer Telecommunications System within that region. Responsibilities 
include: Planning and allocating telecommunications assets to meet requirements; 
correcting outages/trouble encountered in meeting requirements; and analyzing asset 
performance to improve efficiency and effectiveness. [Ref. 30:p. 6-1] 

To meet these responsibilites, N3 is organized into divisions by functional task. 
Each of the three NCTAMS use a near-identical naming and numbering scheme for their 
N3 divisions. The organizational structure of NCTAMS EASTPAC Communications 
Department will be shown here, because it is the NCTAMS used for this research. It’s 
divisions include: [Ref. 36] 

e N3: Communications Officer 

e N3A: Assistant Communications Officer 

e N31: Fleet Message Processing Division 

e N32: AUTODIN Automated Switching Center (ASC) Honolulu 

e N33: Network Operations Center (NOC) 


e N34: Techincal Control Division 


e N35: JFTOC 

e N36: Special Communications Office (SPECOMM) 

e N37: SATCOMM Division 

e N38: Communications Support Division 

With the exception of N38, all NCTAMS N3 divisions are manned 24-hour per 
day, 365 day per year. The supervisor of each division watch section reports 
operationally to the JFTOC JWO. The JFTOC JWO 1s assisted by the Joint Area Watch 
Officer (JAWO) and the Operations Watch Supervisor. Equivalent N3 watchsections, 
with the exception of a JFTOC, are manned at all stations that report operationally to the 
NCTAMS. [Ref. 32] 

4. JFTOC 


a. Mission 


JFTOC’s mission is threefold: “(1) Allocation, management and operation 
of message processing; (2) Management of technical control functions, including Defense 
Communications System (DCS) assets; and (3) Allocation and management of regional 
assets in support of Joint and Fleet Commanders.” [Ref. 29:p. 12] The JFTOC acts as the 
single point-of-contact (POC) for all C4I services for all afloat units and area shore 
commands in its region. It 1s essentially a “one-stop shop” for information services. [Ref. 
29:p. 12} Additionally, the JFTOC Division, through its Tactical Plans (TacPlans) 
Officer/Chief, performs operational and exercise planning for the region. This function 
requires extensive coordination with FLTCINC staff and personnel at other NCTAMS. 


[Ref. 30:p. 6-3] 


b. Functions 


The JF TOC of the immediate future will be able to monitor and manage 
all of the following services: Defense Message System (DMS)-Local Control Center 
(LCC), Joint Maritime System Engineering Cener (JSEC), SATCOM-Fleet Management 
Center (FMC), IMSC, NOC/Domain Name Service (DNS), Information Security 
(INFOSEC), Automated Network Control Center (ANCC), Fleet Center and Fixed 
Submarine Broadcast System (FSBS). [Ref. 29:p. 14] 

5. NOC 

The NOC Division, also known as the PRNOC, provides management services to 
fleet and shore users of classified and unclassified, IP, wide-area networks. They provide 
a full range of network management services including: configuration, fault, 
performance, and security management. Current functionality includes: immediate 
trouble call response, network monitoring, IP address registration and advertisement, 
DNS mail store-and-forward service, router port configuration for fleet and shore units, 
standardardized troubleshooting, and circuit restoral procedures, and World Wide Web 


(WWW) sites for network information. [Ref. 40] 


D. SUMMARY 

The expanding role of the JFOC. to include a full complement of network 
management services, 1s central to the strategic plan of NCTC; goals which are derived 
directly from Navy C4I vision. doctrine, and strategy. As the one-stop shop for 
information services within each region, the JFTOC ensures the warfighter access to the 


right information, at the right time. in the right format. 
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Ill. DEFINING THE SYSTEM PROBLEM 


A. INTRODUCTION 

The second step of the Structured TAFIM process defines the system problem and 
lays the foundation for the remaining steps. Chapter II outlines the role of the JFTOC as 
the single POC in each region for integrated network management services. This chapter 
begins by narrowing the scope of this study to one aspect of this role: fault management. 
Interviews with users of the current FMS reveal its manual nature and their perceptions of 
an ideal system’s capabilities. Next, COTS help desk technology is reviewed to 
determine its appropriateness for use in a target FMS design. The use of one help desk 
application at a major, commercial NOC is discussed to gain greater insight on its 
functionality and applicability. The chapter ends with the establishment of the problem 
statement and outline of the basic criterion and constraints that will be used to solve the 


problem. 


B. FAULT MANAGEMENT 

l. Network Management Overview 

Several models exist to analyze and describe network management. One of the 
most commonly referenced is the Open System Interconnection (OSI) Functional 
network management model developed by the International Standards Organization 
(ISO). (Ref. 59:p. 41] It divides network management into the five areas shown in Figure 
3.1 which include: fault/problem management, configuration/change management, 
performance/growth management, security/access management, and accounting/cost 


management. [Ref. 16:p. 4] Although not recognized as a major functional area, asset 


management, the development and retrival of records on equipment, facilities or 
personnel, allows informed and efficient use of network assets. [Ref. 16:p. 9] This 
research will focus on fault management, because in the author’s opinion, it consumes the 
majority of the JFTOC’s time and effort. 

. Fault Management Overview 

The primary objective of fault management is “to ensure maximum network 
availability”. [Ref. 24:pp. 552-553] Six key phases, displayed in Figure 3.1, provide a 
simple description of this functional area. These include: event notification, logging, 


ticketing, tracking, isolation, and resolution. [Ref. 16:p. 11] 


FAULT MGMT KEY PHASES 


OSI FUNCTIONAL Event Notification 
NETWORK MGMT Logging 
Ticketing 

Tracking 
lsolation/Diagnosis 


Resolution/Correction 





Figure 3.1. Fault Management as Part of the OSI Model. [Ref. 
l6:p. 11] 


Fault management functions may be accomplished using a variety of COTS 
automated tools. As shown in Figure 3.1, a common fault management toolset consists 


of a NMS that uses Simple Network Management Protocol (SNMP) and a help desk 
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application that generates, tracks, and documents trouble tickets. Help Desk applications 
will be explained in greater depth in the next section. Throughout this study, the terms 
outage, trouble, problem, and fault will used interchangeable. Using a NMS and a help 
desk application, fault management key events may be described as follows: 


e Event Notification: The NMS polls the management agents in each network 
device to look for alarm conditions. Alarm conditions are generated when a 
management agent does not answer its poll (indicating device failure) or when 
the parameter returned exceeds a pre-set alarm threshold (indicating 
performance degradation). Selection of appropriate alarm thresholds is critical 
to effective fault management. [Ref. 24:p. 553] Most current NMS products 
perform alarm filtering and correlation to prevent the operator from being 
presented with multiple alarms for the same alarm condition (e.g., multiple 
devices reporting the same trunk outage). [Ref. 1] 


e Logging/Ticketing: Most current NMS products have the ability to export 
alarms to help desk applications; this ability is referred to as automatic trouble 
ticket generation. When the alarm is received, a new trouble ticket is opened 
and information received from the NMS may allow some fields to be completed 
automatically. [Ref. 1] A trouble ticket acts as a consolidated record of all 
events that occur in the efforts to resolve the outage. Logging refers to 
recording trouble shooting information in the trouble ticket. [Ref. 16:p. 6] 


e Tracking: Tracking is the process of checking the progress of internal and 
external personnel in their efforts to resolve the fault. Most current Help Desk 
applications perform event escalation to trigger an alarm that a trouble ticket has 
exceeded some pre-defined, time threshold. [Ref. 16:p. 6] 


e Isolation: Isolation refers to identifying the cause of the fault. This may be 
accomplished using the NMS or with some other system diagnostic tool. 
Identification of the outage cause 1s recorded in the trouble ticket. [Ref.16:p. 6] 


e Resolution: Finally, resolution of the abnormal condition is the last step in the 
fault management process, however, it often requires the performance of a 
configuration/change task (e.g.. moving a circuit to a different satellite access 
due to interference on the original access). [Ref. 16:p. 6} Resolution 
information 1s recorded in the trouble ucket, which ts then closed out. 
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GC; NCTAMS EASTPAC USER ASSESSMENT 

hs. Interview Methodology 

In-person, interviews were conducted with personnel who are either users of or 
technical experts regarding the current FMS. Interviews were approximately one hour in 
length and were taped using a micro-cassette recorder. Subjects were selected from the 
following categories: NCTAMS CO/XO, Department Head, Division Officer, Watch 
Supervisor or Technical Support; and a user at CINCPACFLT. The following staff 
members were interviewed: (Unless otherwise indicated, billets are located at NCTAMS 
EASTPAC.) 

e Commanding Officer 

e CINCPACFLT Communications Officer 

e Communications Officer 

e Assistant Communications Officer 

e JFTOC Officer 

e NOC Officer 

e Tech Control Officer 

e NOC Technical Director 

e NOC Technical Support Contractor 

e LAN Upgrade Project Manager 

e JFTOC Traning Petty Officer 

e NOC Training Petty Officer 

The majority of the interview questions were open-ended in nature and were 


veared toward the interviewees’ experience with the current system based on their job 
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responsibilites. Questions posed to personnel in senior leadership positions were 
specifically tailored to understand users’ perception of: (1) the current system’s 
shortcomings and (2) the capabilities of an ideal system. Questions asked of the 
remaining personnel, on the other hand, were designed to further understand the 
workflow model and business rules that underlie the current system. However, questions 
of both types were asked to all interviewees. 

2. Problem Seto 

Figure 2.2 displays a summary of responses to questions about the current 
systems’ shortcomings. For ease of reading, replies are divided into six categories: 
Information Duplication, Manual Report Generation, Dated (Non-Timely) Information, 
Manual Information Capture, Information Stovepipes Vice Consolidated Data Stores and 
Manual Information Query. Without describing the details of the current system here, 
one gains a sense of its essentially manual nature. 

3: System Wish List 

Figure 2.3 displays a summary of responses to questions about an the capabilities 
of an ideal system. Replies are divided into eight categories: Automatic Report 
Generation, Near-Real Time Information, Automatic Information Capture, Consolidated 
Data Store, Automatic Information Query, Information Views, Information 


Exchange/Communication, and Other. 


PROBLEM SYMPTOMS 


Information Duplication: 

e Recording the same information in station logs, SITREPs, COMSPOTs and e-mail is frustrating 
for watch standers. 

e Reading the same information in station logs, SITREPs, COMSPOTs and e-mail makes tracking 
an outage cumbersome for managers. 

Manual Report Generation: 

e The summary of outages portion of the DSR must be written by the JFTOC Watch Officer each 
day using the information from station logs, SITREPs and COMSPOTs. 

e To generate a Detailed Outage Report (DOR), NCTAMS personnel must extract information 
from station logs, SITREPs, COMSPOTs and DSRs. 

e Tracking and updating SITREPs is a manual process performed using a log book. Updates are 
directed by JFTOC when a SITREP exceeds its estimated time of repair (ETR) or when 
significant new information is obtained. 

Dated (Non-Timely) Information: 

e DSR provides a snap-shot of the troubleshooting and restoral status at the time it was written; it 
does not provide a current situational status. 

e Lack of near real-time outage information during troubleshooting raises frustration levels and 
can lead to “finger-pointing” between NCTAMS and afloat units. 

e NCTAMS and afloat customers often perceive a lack of urgency on the others’ part due to a lack 
of near real-time information. 

Manual Information Capture: 

e Troubleshooting coordination done verbally or via orderwire often results in lost information. 

e Primary exchange of outage troubleshooting and restoral status internal to NCTAMS occurs 
verbally. 

e A large percentage of the information about outages is received on paper. Information on paper 
gets lost and must be typed into the station log. 

e Watch standers find it cumbersome to record troubleshooting steps in the log as they occur. 
Instead, they write down key events and go back later to type them in. 

information Stovepipes vice Consolidated Data Stores: 

¢ COMSPOTSs are difficult to track, because answers and replies do not directly follow each other 
when message traffic 1s sorted by date-time-group (DTG). 

e JFTOC must query NCTAMS divisions or customers for latest status on outages. 

e Divisions troubleshooting an outage have access to neither JFTOC’s nor each others’ station log; 
all station logs are text files located on stand-alone PCs. 

¢ NCTAMS must maintain numerous historical files of outage information, including: station 
logs, SITREPs, COMSPOTs, As-occurring SITREPs and orderwire files. 

e Station logs entries are made by DTG; they are not grouped by outage. 

Manual Information Query: 

¢ COMSPOTs do not contain enough details of the troubleshooting actions taken to resolve the 
Outage 

e No automated method exists of retrieving outage information by circuit, time period or reason 
for outage. automated statistical analysis is, therefore, impossible. 

e Remaining updated on the status of outages consumes a significant portion of a manager's day. 


¢ Briefing managers on the status of outages consumes a significant portion of a JFTOC Watch 
Officer's day. 


Figure 3.2. Problem Symptoms. 


24 


SYSTEM CAPABILITIES WISH LIST 


Automatic Report Generation: 

e Compose DSR and COMSPOT replies from information in the database. 

e Generate the DSR automatically. 

Automatic Information Capture: 

e Enter data with input device that does not require typing. 

Consolidated Data Store: 

e Serve as a central repository of all information that was gathered and exchanged between 
NCTAMS and customer during an outage. 

e Incorporate all the information from COMSPOTs and SHF/EHF Quick Look Messages into one 
data source. 

e Create one record of an outage available on a near-real time basis to all departmental personnel. 

e Compile one log of troubleshooting actions for all divisions. 

e Record performance of watch duty functions, such as performance of proper watch relief 
procedures, in same data source as outages. 

Automatic Information Query: 

e Compare scheduled (maintenance) outages against unscheduled outages. 

e Ability to go to a “home page” and find the status of certain CASREPs. 

e Provide performance trend information on communications services provided. 

© Query a database about similar outages to see troubleshooting step that resolved outage. 

Unique Information Views: 

e Display graphic representations of outage information by circuit, RFO and time period to allow 
correlation between a type of outage and some other factor. 

@ Provide Operations Department managers with the same near-real time information as the 
JFTOC Watch Officer. 

e Provide an executive summary level view of “high priority” outages to operational commanders. 

e Make troubleshooting information available to units that want it vice all units, all the time. 

Information Exchange/Communication: 

e Access outage information from the users’ desktop/office PC. 

e Keep customers informed of outage resolution progress and how their outage compares in 
priority to others. 

e Provide a means for an afloat customer to communicate the results of troubleshooting actions 
more quickly and capture that information for future analysis. 

e Provide a method of communicating within the department about outages. 

e Provide an incentive for more “teamwork” and less “finger-pointing” between NCTAMS and 
afloat units. 

e Show customers that NCTAMS is performing systematic troubleshooting. 

e Exchange information between the NCTAMS, especially the Network Operations Centers 
NOCs 

e Conduct better tumovers between watch sections and NCTAMS in the event of responsibility 
sharing. 

Other: 

e Run ina Windows environment. 

© Control access’privileges to data by user 


Figure 3.3. System Capabilities Wish List. 
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Dp: HELP DESK TECHNOLOGY REVIEW 


Help desk software was introduced above, as a component of a FMS that 
performs trouble ticket functions. In this section, the term “help desk” will be defined, 
help desk software will be described and the use of help desk software at a commercial 
teleccommunications facility will be outlined. 

Le Help Desk Definition 

Help desks have traditionally been associated with end user support, but their role 
continues to evolve with the expansion of network computing. (Ref. 61] Help desks may 
be considered internal or external. Internal help desks address IT problems of employees 
within an organization. The organization need not be limited to a single building, but 
may in fact, be nationally or globally distributed, as long as they remain within a single 
corporate structure. External help desks aid customers with IT problems concerning 
products purchased from that organization or, in the case of an outsourced help desk, a 
third party. [Ref. 27:p.5] Examples of this type of help desk abound in the form of toll- 
free customer service numbers. In the author’s opinion, the functions performed by a 
JFTOC more closely resemble those of an internal help desk than an external one. 
Certainly, however, the JFTOC’s customers, primarily ships, are more mobile and 
geographically disbursed than those of most internal help desks. 

Zz. Help Desk Software 


4a. General Description 


Help desk software may be described as customized database applications 


that provide for storage and retrival of information on customers/employees, trouble 
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reports made to an organization’s support center, and some means of locating information 
to aid support personnel in resolving reported problems. [Ref. 57:p.17] 

Help desk software functionality has evolved rapidly in recent years. No 
longer used solely for tracking trouble tickets, help desk applications are converging with 
desktop, network, and systems management products, as well as, software used to track 
sales and marketing operations. In addition, help desk products integrate with other 
software, such as e-mail applications, report writers, and NMS platforms, to achieve even 
greater functionality. [Ref. 58:p. 52] The term “consolidated service desk” is used to 
describe software that can perform “asset/change management, external customer 
support, defect management, and product management.” [Ref. 60:p. 30] 


b. Market Overview 


The number of vendors offering products with reported help desk 
functionality decreased from approximately 175 in February 1995 [Ref. 28:p. 35] to just 
under 100 in January 1997. [Ref. 14:p. 52]. Some analysts attribute this decrease to the 
research and development (R&D) resources needed to achieve the greater functionality 
and integration capabilities discussed above. [Ref. 58:p. 52] There is currently no clear 
market leader [Ref. 14:p. 52}, but based on the author's research, there are a group of 
approximately 10-15 help desk products that are frequently referenced as top performers 
in IT trade publications. 

Meanwhile, to describe help desk sales as “growing”, would be a senous 
understatement. According to industry analysts, the total market grew from $160 million 
in 1995 to $500 million in 1996 [Ref. 14:p. 35] and 1s expected to reach $1.8 billion by 


2000. [Ref. 28:p. 52} Additionally. more than 50 percent of Fortune 1000 companies 


indicate that they will replace their help desk systems by 2000. [Ref. 28:p. 51] These 


replacements are reportedly to take advantage of the “substantial competitive advantage” 


that newer systems will offer. [Ref. 55:p. 86] 


Cc. Functionality 


Figure 3.4 provides a list of help desk application critical features. 


Functionality is divided into six categories: platform/operating system/database support, 


integration, external platform functionality, internal platform functionality, problem 


management capabilities, and product architecture. 


d., Industry Trends 


Three industry trends are important to note: 


e Client/Server Environment: The majority of help desk applications run in a 


client/server environment. Client machines generally hold the user interface 
while the server holds the application logic and DBMS. Some major vendors 
offer a three-tiered client/server approach where the application logic and 
DBMS are placed on seperate servers. [Ref. 28:p. 36] Three-tiered client/server 
systems are theoretically more scalable, robust and flexible. As a percentage of 
all client/server applications, three-tiered products are projected to grow from 
five percent in 1995 to 33 percent in 1998. [Ref. 38:p. 19] 


Open Architecture: There is a general industry trend toward an open 
architecture which allows interface between the help desk software and a variety 
of third party applications including: database management systems (from 
vendors such as Oracle Corp., Sybase Inc. and Microsoft Corp.), report writers 
and document managment systems. [Ref. 28:p. 36] Other interfaceable products 
include: NMS platforms, telephony tools, paging software, knowledge 
databases, and asseVinventory management applications. [Ref. 49] 


e Internet Access: Many major help desk vendors have added Internet links to 


their products to allow customers to log problems. schedule service calls or 
download information about problems or products. [Ref. 54] Vendors offer a 
separate Web server package that provides access to their main help desk 
application using a Web browser such as Nestscape Navigator or Microsoft 
Internet Explorer. Customers use their browser to enter trouble tickets or to 
check the status of trouble tickets that remain open. [Ref. 45] 
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HELP DESK SOFTWARE FUNCTIONALITY 


Platform/Operating System/Database Support 
— Platform (e.g.. HP, Sun, PC Compatibles) 
— Operating System (e.g.. HP-UX, Solaris, MS NT) 
— Database (e.g.. Sybase, Oracle, MS SQL) 

Integration of Third Party Applications (e.g..) 
— Database Management Systems (DBMS) 
— NMSs 
— E-mail/Telephony/Paging 

External Platform Functionality 
— Reporting Tools 
— Ease of Installation & Customization 
— Development Tool Kits 

Internal Platform Functionality 
— Graphical User Interface (GUI) 

— Expert Systems/Automated Problem-Resolution 
—  Security/Backup 

Problem Management Capabilities 
— Sorting 
— Call and Problem Management 
—- Remote Problem Management 

Product Architecture 
—  Product/Client/Database Architecture 
- Application Scalability 





Figure 3.4. Help Desk Functionality. [Ref. 15:pp. 58-59] 


e. Additional Help Desk Resources 


In the author's opinion. the Microsoft Sourcebook for the Help Desk. 
Second Edition provides the most comprehensive anthology of help desk resources. 


These include: web sites, books. publications, and organizations, that provide additional 
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information about help desk operations, software (including: functionality, vendors, 


products and prices), tools, consultants, and outsourcers. 


f Example of Help Desk Software Use: Pacific Bell Mobile 
Services 


Information was provided by Steve Curley, NOC Manager of Pacific Bell 
(PacBell) Mobile Services located in Pleasanton, California. PacBell Mobile Services 
operates a digital Personal Communications System (PCS) network in California and 
Nevada. The network is divided into four regions: Bay Area, Los Angeles, 
Sacramento/Nothern Nevada and San Diego/Southern Nevada. [Ref. 39] PacBell Mobile 
Services began operation in early 1996. Projections place the subscriber rate at 330 
thousand subscribers at the end of 1997 with growth to one million within three years. 
[Ref. 6] 

The role of the NOC, as a 24-hour operations facility, includes alarm 
surveillance and fault investigation/administration, real-time traffic monitoring, planned 
work administration, integration of new sites/equipment, customer related fault 
investigations, network security investigations, change management controls, liaison with 
all third party agencies, (e.g., a utility company) and first line support. The NOC 
monitors network elements to the level of the radio transceiver that broadcasts the signal 
in each cell. The role of the NOC does not include customer interaction; customer 
service is a function of another work center called the Customer Care Organization. [Ref. 
39] 

PacBell uses seven applications to perform the different aspects of 
network management. At the time of this interview, the NOC is selecting a NMS to 


Integrate these seven programs. Figure 3.5 shows the planned configuration. The 
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remainder of this discussion will focus on the help desk application that PacBell uses for 
its FMS: the Remedy Action Request (AR) System. [Ref. 39] Remedy AR System is 
also used for the Planned Work System (PWS), but the PWS is not an integral part of this 


discussion. 


OSS OSS 
Region 1 Region 2 


OSS 
Region 3 


NMS Network Management System, To Be Determined 

FMS Fault Management System, Vendor’ Remedy 

PWS Planned Work System, Vendor Remedy 

NCIS Network Coverage Information System, Vendor Map Info 
ISS Infrastructure Support System. Vendor: SQL System 

TIMS Transport Inventory Management System, Vendor Isicaid 
NPS Network Performance System, Vendor Metrica 

OSS Operavons Suppon System, Vendor Ericsson 





Figure 3.5. PacBell Mobile Services Planned Management Configuration. 
[Ref. 39] 


The AR System plays a critical role in the operation of both the NOC and 
Customer Care Organization. The NOC uses the software to create trouble tickets, assign 
technicians and track problem resolution. The Customer Care Organization uses it to 
provide customers with the status of outages in their coverage areas; showing customers 
that PacBell is taking action to resolve the problem before the customer reports it. Table 
3.1 provides summary of the fault management workflow model and business rules that 


are incorporated into the AR System. Automatic trouble tucket generation, ticket 
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categorization by severity, event escalation and remote access capability are important 
AR System features. 


Table 3.1. Fault Management Workflow and Business Rules in Remedy AR System. 
[Ref. 6] 


|! FAULT MANAGEMENT STEPS BUSINESS RULES al 


Remedy receives fault information from | Unique outage identifier is assigned. 

ee 
Remedy generates trouble ticket. Only one trouble ticket is allowed per 
pa See wel iaacas le 


NOC assigns technician to trouble ticket. | Technician assignment is based on 
number and severity of tickets already 







assigned. 
Remedy pages technician (using paging | Technician receives element affected, 
| software). problem description and phone number to 
: answer the page. 
| Techician acknowledges the page by | Pages technician’s supervisor if page 1s 
calling phone number tied into Remedy. not answered within 10 minutes. Changes 
ticket status. 


| Technician logs into Remedy using laptop | Changes ticket status and tracks time to 
| and wireless phone. drive to site. 


Technician estimates if time to repair will | If repair estimation not made within two 
exceed four hours (standard restoral time | hours, Remedy pages  technician’s 
for outages that affect customers). Supervisor. 
| Technician turns outage over to supervisor | Estimation is based upon supervisor’s 
| to determine restoral time if outage will | judgement. 
exceed four hours. 




























































PacBell has approximately 200 AR System users. This application allows 


assignment of read/write permissions down to the individual user level. PacBell manages 
read/write permissions using the following business rules: trouble tickets may only be 
assigned to regional field technicians or engineering personnel: the assigned person is the 
only one given write penn cion: but all other AR System users have read permission to 
all trouble tickets. AR System ts used for trend analysis, including generation of weekly 


and monthly reports. PacBell managers also use another Remedy product called 
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Flashboards to provide a real-time, graphical representation of trouble ticket metrics such 


as the number of open trouble tickets. [Ref. 6] 


E. FORMAL PROBLEM STATEMENT 

Based upon Chapter II and III’s discussion of the topics listed below, the system 
problem will now be defined. Topics include: 

e C4] doctrine and policy 

e NCTAMS/JFTOC mission and organization 

e Structured TAFIM process 

e NCTAMS EASTPAC user assessment 

e Help desk software technology review 

System Problem Statement: The JFTOC performs the roles of both a NOC, 
providing network management services, and an internal help desk, addressing 
information service problems of its fleet customers. The current FMS employed by the 
three NCTAMS is functionally inadequate for the JFTOC to achieve the CNMP’s goal of 
a “one-stop shop” [Ref. 29:p. 12] for network management services. Interviews with 
system users reveal that the system’s manual nature results in: use of non-timely 
information in troubleshooting and decision-making; duplication of outage information in 
numerous data stores: manual retrival of outage information for report preparation and 
trend analysis: and an inability to share outage information both between NCTAMS work 
centers and between JFTOC and its customers. 

Chapter H introduces the Structured TAFIM Process as the methodology that will 
be used to define a target system and migration path to achieve that system. At this point, 


however, it is appropriate to outline the basic criterion and constraints that will be used to 


solve this problem. One valid way to express these concepts is through use of a 
mathematical programming template; maximize or minimize some objective function 
subject to certain constraints. Applying this model to systems development, provides the 
following choices for problem formulation: [Ref. 20] 
e Maximize System Performance (Over its Lifecycle) 
Subject to: System Cost < Project Budget 
e Minimize System Cost (Over its Lifecycle) 
Subject to: System Performance = Minimum System Performance 
Based upon the Quadrennial Defense Review’s projections for DOD’s fiscal 
environment, the author believes the second formulation option is prudent. Problem 
constraints will not be introduced in detail] until Chapter V, but Figure 3.6 provides the 


essential elements of the formulation model including some constraint examples: 


Minimize System Cost (Over its Lifecycle) 


Subject To: (1) System Quality = Minimum System Quality 
(e.g., availability, response time, scalability) 


(2) Information Quality > Minimum Information Quality 
(e.g., information timeliness, information relevance) 


(3) Technology 
(e.g., help desk applications, DBMSs, processor speeds) 


(4) Existing Information Infrastructure/Policy 
(e.g.. SIPRNet, existing Classified LAN) 





Figure 3.6. Problem Formulation Model. [Ref. 19] 
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F. SUMMARY 

Definition of the system problem and establishment of the criterion and 
constraints that will be used to solve it are the end products of step two of the Structured 
TAFIM Process. They ensure the common “sheet of music” for all future discussions 


about the baseline system, target architecture and migration paths development/selection. 
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IV. ASSESSING THE BASELINE SYSTEM 


A. INTRODUCTION 

The third step of the TAFIM process, assessing the baseline system, reveals the 
character and state of the current system. Chapter III defined the system problem as one 
of designing a FMS that minimizes cost over its lifecycle subject to the constraints of 
quality, information quality, technology, and existing information infrastructure. This 
chapter outlines the policy, processes, external entities, data stores, and data flows which 
comprise the Baseline FMS. Additionally, the physical aspects of the system, including: 
networks, hardware, software, and data storage are briefly described. Finally, this 
chapter concludes with a discussion on the implementation of a classified LAN at 


NCTAMS EASTPAC, since it is relevant to the design of a target FMS. 


B. POLICY AND REPORTS 
| Policy 


A. Fleet Operational Telecommunications Program (FOTP) 


The Fleet Operational Telecommunications Program (FOTP) Manual is 
promulgated by COMNAVCOMTELCOM for implementation by CO's of NCTAMS. 
It provides policy for the organization, control and management of NAVCOMTELCOM 
shore activities and automated systems in the Naval Computer and Telecommunications 
Svstem (NCTS) over which NAVCOMTELCOM exercises configuration control. 
Topics covered include: COMNAVCOMTELCOM organization for operations; 
command relationships. NCTAMS internal organization and functions: NCTS 


operations and readiness; and required reports. [Ref. 30:p. 1-1] 


Based upon the guidance of the FOTP Manual, procedures for specific 
operations and tasks are promulgated via a family of documents. Figure 4.1 shows the 


hierarchy and relationship of NAVCOMTELCOM procedural documents. 


NAVCOMTELCOM Yv : <[Poltey to Procedure 


LANT/MED 
FIP 


OCEAN AREA 


5 pl Joint LANT/MED Joint PACIFC/ 
CIB/CIA INDIAN 


CIB/CIA 


‘>| LANT CIB/CIA MED CIB/CIA EASTPAC CIB/CIA lq - é 


NCTAMS: 


se 
* 
e 


A LANT SOPs MED SOPs EASTPAC SOPS |g. : 


Figure 4.1. Relationship of NAVCOMTELCOM Policy and 
Procedural Documents. [Ref. 30: pp. 7.1-7.2] 





COMNAVCOMTELCOM publishes a _ series of Naval 
Telecommunications Procedures (NTPs) to establish standardized, NCTS-wide 
procedures. The NCTAMS, in turn, issue Fleet Telecommunications Procedures (FTPs) 
to establish procedures that are ocean-area specific. There are two FTPs; one for the 
LANT/MED ocean-area written jointly by NCTAMS LANT and NCTAMS MED, and 
one for the PACIFIC/INDIAN ocean-area written by NCTAMS EASTPAC. If FTP 
procedures are standardized throughout the NCTS, they are then incorporated into the 


NTPs. Each NCTAMS establishes procedures which are unique to their region using 
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Communications Information Bulletins (CIB) and Communications Information 
Advisories (CJA). As procedures emerge that are common to an ocean area (e.g., 
LANT/MED), a joint CIB (e.g., NCTAMS LANT/MED) is issued. These joint CIBs are 
incorporated into the respective FTP upon revision. Finally, each NCTAMS establishes 
Standard Operating Procedures (SOPs) which provide step-by-step procedures for 
performing important operational and administrative tasks. [Ref. 30: pp. 7.1-7.2] 


b. NCTAMS Standard Operating Procedures (SOPs) 
The FOTP establishes the organization of SOP into the following 
categories: 
e ALFA: Administrative 
e ECHO: Emergency 
e INDIA: Information 
e OSCAR: Operational 
e ROMEO: Reports 
e TANGO: Training 


Using these categories, each NCTAMS N3 division promulgates their 
won task specific SOPs. For SOPs to remain accurate, periodic revisions must occur 
which many include adding new SOPs. Detailed and comprehensive SOPs play a 
significant role in watchstander training and qualification. [Ref. 30:pp. 7.2-7.3] 

om Reports 
The FOTP Manual provides guidance on the reports that each NCTAMS 1s 


required to submit or receive. The following reports are pertinent to the Baseline FMS: 


a 


a. COMSPOT 


All ships are required to submit a Special Communications Report 
(COMSPOT) to the NCTAMS “anytime significant communications difficulties are 
encountered”. [Ref. 30:p. 8.2] COMPSOTs are submitted via naval message 
(AUTODIN) in accordance with NIP-4. The message sent by the NCTAMS 
responding to a COMPSOT 1s likewise referred to as a COMSPOT. 

b. CASREP 

NCTAMS and NCTS are required to submit an Equipment Casualty 
Report (CASREP) via naval message on any failed communications equipment. (Ref. 
30:p. 8.9] The FOTP Manual indicates that CASREPs submitted by a NCTAMS are to 
include COMNAVCOMTELCOM as an action addee and the FLTCINC as an info 
addee. [Ref. 30:p. B.1] Ships that have submitted a COMPSOT and seule failed 
communications equipment as the reason for outage (RFO) generate a CASREP that 
includes NCTAMS as an info addee. 

Cc. Detailed Outage Report (DOR) 

A DOR 1s a step-by-step breakdown of all actions taken or events that 
occurred in the resolution of a telecommunications outage. A DOR Request message 1s 
normally sent by an afloat unit of staff toa NCTAMS. 

d. As-occurring SITREP 

As-occurming Situation Reports (SITREPs) are sent by a NCTAMS to 
NAVCOMTELCOM in the event of a telecommunications outage or inclement weather 
condition that threatens to impair regional operations. The FOTP Manual provides 


specific reporting guidelines, but general categories of events include: Inclement 
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Weather (e.g., hurricane, typhoon), Bomb Threat/Fire/Terrorist Threat, Function Shifts 
(e.g., JFTOC, Fleet Broadcast (FLTBCST) Broadcast Control Station (BCS)), and Loss 
of Telemetry, Tracking and Control (TT&C). As-occurring SITREPs use a standard 
template consisting of eight fields to describe: the outage, alternate means of 
telecommunications delivery, and efforts to resolve the outage. They are prepared using 
a DOS editor template and numbered starting with 001 for the first SITREP issued on 
the first day of each month. Each successive amplifying SITREP is designated with a 
letter starting with an “A”, e.g., OO1A, 001B. The final As-occurring SITREP in a series 
is designated as such, e.g., 001 FINAL. [Ref. 30:pp. 8.2-8.4] 

Until recently, As-occurring SITREP were _ transmitted to 
NAVCOMTELCOM via the Global Navy Orderwire Network (Nownet); a secure, 
point-to-point circuit that connects the NAVCOMTELCOM Naval Computer and 
Telecommunications Operations Center (NCTOC) with each NCTAMS. In turn, the 
NCTAMS are connected to FLTCINCs, Numbered Fleet Commander’s Flagship, and al! 
NCTS in their region. [Ref. 30:pp. 7.6-7.7] The Global Nownet node at NCTOC is 
currently disabled pending conversion of the Nownet to SIPRNet. The current 
procedure for submitting an As-occurring SITREP is via secure FAX or naval message 
(e.z.. Fleet Advisory). [Ref. 53] 

e. SITREP 

SITREP is the term used to describe As-occurring SITREPs sent to the 
JFTOC by a NCTAMS N3 division, NCTS, or any other telecommunications facilities 
within that NCTAMS region. The similarities to an “As-occurring SITREP™ include: 


format. numbering system. and transmission to NCTAMS via Global Nownet. The 
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major difference between them is the categories of events that are reportable. Whereas 
As-occurring SITREPs are required for major events that threaten the operation of a 
region, SITREPs are required for circuit/system outages that meet or exceed a certain 
time threshold. Reportable outages and corresponding time thresholds are listed in the 
FOTP. Each NCTAMS may also use this guidance to determine when regional 
activities must submit SITREPs, or it may institute stricter guidelines by shortening time 
limits or including other circuits/systems. [Ref. 30:p. 8.6] 

Table 4.1 shows the number of SITREPs handled by NCTAMS 
EASTPAC JFTOC during the months of April, May, June, and July 1997. Figure 4.2 
provides a breakdown of April’s SITREP by category. During that month, 
approximately 70 percent of the SITREPs concern fault/outages and 30 percent 
document configuration changes. Within these two categories of Fault Management and 
Configuration Management, sub-categories are established to show general trends. The 
most significant sub-category within Fault Management is SHF Trunk Outages which 
account for approximately 30 percent of the total number of SITREPs. These statistics 
based upon only one month of data are not statistically significant, but they are useful to 
give the reader a general understanding of the type of faults managed by the JFTOC. 


Table 4.1. NCTAMS EASTPAC SITREP Statistics for April-July 1997. [Ref. 38] 


Se 
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NCTAMS EASTPAC SITREPS FOR APRIL 1997 


FAULT MANAGEMENT 


SHF TRUNK 60 31.09% 
VLF* ( * INCLUDES 2 HAZCONS) 14. 7.25% 
LF 1 0.52% 
SATCOMM TERMINALS* 10 5.18% 


(FSC-79, FSC-78, GSC-52) 
* INCLUDES 4 HAZCONS 


SIPRNet/NIPRNet 16 8.29% 


SHF CIRCUITS 2 1.04% 
(STEL, JDISS) 


UHF CIRCUITS 16 8.29% 
(TADIXS, CUDIXS, OTCIXS, SSIXS, 

DAMA SUITE) 

LANDLINE TRUNKS 4 2.07% 
MESSAGING SYSTEMS* 8B 4.15% 


(NAVCOMPARS, PCMT, GATEGUARD 
MARCEMP, VERDIN, FLT BROADCAST) 
* INCLUDES 2 HAZCONS 


ANCC Soo MONO 
CHANGE TO CIRCUIT CONFIGURATION 19 9.84% 
(BKS, BRS, BCA, SATELLITE ACCESS) 


SYSTEM ACTIVATION emeeO92% 


SHF SCHEDULED OUTAGE 29 15.03% 
(MAN ALOFT, DRILLS, TESTING) 


NON-SHF SCHEDULED OUTAGE i 363% 
(VLF, LF, HF) 

SUB TOTAL 56 25.02% 
CANCELLED SITREP >. (sae 
SUB TOTAL 3 T.55% 





GRAND TOTAL TSS T00.00% 





Figure 4.2. NCTAMS EASTPAC April 1997 SITREP. 
[Ref. 38] 
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i Daily Summary Report (DSR) 
The Daily summary Report (DSR) provides COMNAVCOMTELCOM 


with a snap-shot of the significant telecommunications events that occurred in each 
NCTAMS region. Sent each day at 0300 Zulu (Z), it covers the period of the previous 
radio day (RADAY), 0001Z-2359Z. Areas covered include: FLTBCST and Common 
User Digital Information Exchange Subsystem (CUDIXS) Status; Non-Training High 
Frequency (HF) Terminations Status; Defense Satellite Communication System (DSCS) 
- Super High Frequency (SHF) Terminations Status; Autodin Switching Center 
(ASC)/Naval Communications Processing and Routing System (NAVCOMPARS) 
Status; Special Interest Items; Current Exercises; and Future Exercises. The Special 
Interest Items section includes a summary of events surrounding each outage which 
meet the FOTP Manual SITREP reporting criteria. [Ref. 30:pp. 8.4-8.6] 


g. Station Logs 


Station logs, also known as radio logs, are records of all significant 
events that occur during the 24 hours of a RADAY. Each NCTAMS N3 division that 
performs watchkeeping functions is required to maintain logs. As the regional network 
manager, the JFTOC’s logs contain a chronalosie listing of all outages reported, 
SITREPs received from regional sites, As-occurring SITREPs_ sent to 
NAVCOMTELCOM, follow-up outage information received, outages resolved, final 
SITREPs received, and final As-occurring SITREPs sent. Additionally, administrative 


events such as watch turnover and personnel issues are recorded. 
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c FMS DATA FLOW DIAGRAMS (DFD) 

Interviews conducted with NCTAMS EASTPAC personnel and the author’s 
experience as a former JWO and JFTOC Division Officer at NCTAMS LANT provided 
the information required to model the baseline system using Data Flow Diagrams 
(DFD). Diagrams were kept general enough to allow future adjustments to model 
specific practices of any one NCTAMS. Appendix B provides a review of DFD 
conventions and methodology. 

L Context Level Diagram 

Figure 4.3 shows the Baseline System Context Level Diagram. The NCTAMS 
FMS System is represented to include processes that occur within and between 
NCTAMS N3 divisions. All other stakeholders such as customers, regional sites (e.g., 
NCTS), and Operational Commanders (e.g., FLTCINC) are treated as viii entities. 
The boundaries defined for these system are intended to focus attention on the extensive 
amount of data flow between divisions and data storage within divisions. 

ee Level Zero Diagram 

Figures 4.4-4.6 contain the Baseline System Level Zero Diagram with its nine 
processes. external entities, data flows, and data stores. The following discussion 
provides insight into the methodology used to model the Baseline FMS. A detailed 
description of each process will be provided in the next subsection with each Level One 
Diagram. 

2. Processes 
The nine processes in the Level Zero Diagram include six that parallel the 


key phases of fault management described in Chapter III. These include: Receive 
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Notification of Outage, Log Outage, Create SITREP/As-occurring SITREP, 
Troubleshoot Outage, Track and Update SITREP/As-occurring SITREP, and Close-out 
Records Upon Resolution. The other three, Processes Six, Eight, and Nine, provide a 


graphical representation of the reporting and managerial aspects of the system. 


BASELINE SYSTEM Operational 
CONTEXT LEVEL DIAGRAM Commanders 


As-occurring SITREP 


Outage Report bao Outage Status Query 
NCTAMS Outage Response Outage Status Response 
NCTAMS 


NCTS Management NCTS 
Troubleshooting Status Query g Oeiailed et eecemieee 
system Re 


Troubleshooting Status Response 


Daily Summary Report 


Operational Commander's 
Troubleshooting Pnorities 


Operational 
Commanders 





Figure 4.3. Baseline Context Level Diagram. 


46 


BASELINE SYSTEM 
LEVEL ZERO DIAGRAM 
Outage PROCESSES 1-4 
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Figure 4.4. Baseline Level One Diagram: Processes 1-4. 
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PROCESSES 5-8 


; Customer 
Track & Reineved Outage NCTS 


Update Status Noles 


SITREP/ 
As-Occurring Sxtuved oveoe DOR 


SITREP 
Retneved OW 


SITREP 


Retneved Staton 
Log info 


ol 

Retneved As-Oce SITREP Se 
etev 

Wl SITREP Track p Close-out Info into 


ina OOM aro 
COMSPOT Info i 7 
COMPSOT Foldey| _Closed-Out COMSPO 
Staton Log 
j To Arctyve 
o7 As-Oce SITREP | Close-out os Log Archive 
oid Crsed-Ou As-oce SITREP 


Records Ordereare Fis 


pias | Reemeveatnare | peo aera 
rs pif Orcerane Arn 
Resolution] ,. oc. simree 
inal As-occurnng SITREP To SITREP 
bf Rowe | 


Final COMSPOTs 


To Acctyve 
D149 COMPSOT Arctwe 


STREP 


To Arcteve bs SITREP Avctove 





Figure 4.5. Baseline Level Zero Diagram: Processes 5-8. 
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BASELINESYSTEM—s_— 
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Figure 4.6. Baseline Level Zero Diagram: Processes 9. 


b. External Entities 


The following categories of external entities are used in both the Baseline 


and Target System DFD: 


e Operational Commanders: This category includes FLTCINCs, Numbered Fleet 
Commanders, DISA, and NAVCOMTELCOM. Other operational 
commanders may interact with the NCTAMS FMS depending upon the 
specific telecommunications tasking. 


e Customer/NCTS: Customer and regional sites are grouped together into one 
category, because they both report outages to the JFTOC. Customers are 
primarily afloat units but also include those shore commands which receive 
service directly from the NCTAMS. Regional sites include all NCTS, 
NCTAMS Detachments (NCTAMS DET). Naval Computers and 
Telecommunications Detachments (NAVCOMTELDET), Naval 
Telecommunications Centers (NTCC), Anu-Submarine Warfare Support 
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Communications (ASCOMM), or Special Communications Sites (SPECOMM) 
that report operationally to the JFTOC. [Ref. 30:p. 3-1] 


Cc. Data Stores 


Data stores include a combination of paper and flat files located on stand- 
alone PCs. The Level Zero Diagram shows 13 data stores. The number of data stores 
increases to 20 in the Level One Diagram. The additional data stores are the result of 
showing both JFTOC and Division data stores at the Level One level. In actuality, 
however, the number of stores is much higher, because there are seven operational 
divisions ina NCTAMS EASTPAC N3 Department. This places the actual number of 
data stores at 68 (12 JFTOC data stores + (8 data stores/division X 7 divisions) = 68). 


Table 4.2 categorizes the Level Zero data stores as either paper or electronic flat files. 








Table 4.2. Level Zero Data Stores. 


[Number [Name ——~S~S~*Y Paper lectronic 
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d. Data Flows 


Data flows are too numerous to discuss individually, however, the Level 
Zero DFD provides a clear picture of one significant fact; The vast majority of the data 


flows are between processes and data stores. In this case, this means that the 
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preponderance of the work performed within the system involves putting information 
into and removing it from paper or electronic, flat files. 

a Level One Diagrams 

Processes One through Eight, shown in Figures 4.4 and 4.5, are expanded or 
“exploded” into child processes to form the Baseline System Level One Diagrams; these 
are shown as Figures 4.7 through 4.14. Accompanying each Level One Diagram is a 
detailed description of each data flow. Process Nine, shown in Figure 4.6, is not 
exploded to a Level One Diagram, because it does not require further description via 
sub-processes. 


a. Receive Notification of Outage 
Figure 4.7 shows the Baseline FMS Process One, Level One Diagram. 
Process 1.1, Receive Outage Notification - JFTOC data flows are 
described as follows: 
e Process one is initiated when JFTOC receives Outage Report from: 

e Customer (afloat or ashore unit) via COMSPOT, phone or orderwire entry. 

e Regional NCTS via orderwire entry or phone. 

e N3 Division via orderwire entry or phone. 


e In event of customer/NCTS notification, JFTOC sends Division Request for 
Outage Confirmation. 


e Paper copies of COMSPOTs are stored in JFTOC COMSPOT Folder. 
e Notes taken during phone calls are stored on JFTOC JWO Note Pad. 


e Orderwire entries are stored electronically in JFTOC Orderwire File. 


Sl 
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Figure 4.7. Process One: Receive Notification of Outage. 
Process 1.2, Receive Outage Notification - Division data flows are 


described as follows: 


e Division receives Outage Report from: 
e Customer via COMSPOT, phone or orderwire entry 
e Regional NCTS via orderwire entry or phone 
e Internal alarms or monitors 

e Depending upon whether JFTOC or Division learns of outage first, Division 
sends Division Outage Notification or Outage Confirmation to JFTOC via 
phone or orderwire. Outage Confirmation/Division Outage Notification starts 


the troubleshooting process. 


e COMSPOTs are stored in Division COMSPOT Folder. 
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e Notes taken during phone calls are stored on Division Watch Supervisor (WS) 
Note Pad. 


e Orderwire entries are stored electronically in Division Orderwire File. 


b. Log Outage 


Figure 4.8 shows the Baseline FMS Process Two, Level One Diagram. 
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Figure 4.8. Process Two: Log Outage. 
Process 2.1, Log Outage - JFTOC data flows are described as follows: 


e Outage information from JFTOC COMSPOT Folder, JFTOC JWO Note Pad 
and JFTOC Orderwire File form JWO’s mental model of the outage. 


e JWO enters Initial Notification Info into JFTOC Station Log regarding outage 
notification to a DOS-based., flat-file on a stand-alone PC. 


e JFTOC makes Initial Status Query to Division for any additional information 
received since Outage Report was received. 


Process 2.2, Log Outage - Division data flows are described as follows: 
e Outage information from Division COMSPOT Folder, Division WS Note Pad 


and Division Orderwire File form Division WS’s mental model of the outage. 
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e Watch Supervisor enters Initial Notification Info into Division Station Log 
regarding outage notification to a DOS-based, flat-file on a stand-alone PC. 


e Division provides Initial Status Response to JFTOC. 


C. Create SITREP/As-occurring SITREP 


Figure 4.9 shows the Baseline FMS Process Three, Level One Diagram. 
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Figure 4.9. Process Three: Create SITREP/As-occurring SITREP. 
Process 3.1, Task Division to Generate SITREP - JFTOC Division data 


flows are described as follows: 


e Process three is initiated in accordance with NCTAMS Business Rule (BR) 
regulating Timing of Initial SITREPs. 


e JFTOC obtains next SITREP number from JFTOC SITREP Tracking Log, a 
manual log book. 
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e JFTOC sends SITREP Tasking and SITREP Number Assignment to Division 
via phone or orderwire to generate initial SITREP. 


Process 3.2, Generate SITREP - Division data flows are described as 


follows: 


e Division pulls Retrieved Outage Info from Division Station Log. 
e Division prepares Initial SITREP. 
e Division places a paper copy of Initial SITREP in Division SITREP Folder. 


e Division places SITREP Info in Division Station Log to document Initial 
SITREP issuance. 


e Division forwards Initial SITREP electronically to JFTOC via orderwire or 
manually by messenger. 


Process 3.3, Record SITREP - JFTOC data flows are described as 
follows: 
e JFTOC receives Initial SITREP from Division. 
e JFTOC files Initial SITREP in JFTOC SITREP Folder. 


e JFTOC makes electronic entry of SITREP Info in JFTOC Station Log to 
document initial SITREP creation. 


e JFTOC manually enters SITREP Tracking Information (i.e. SISTREP Number, 
Division Assigned, Subject, Down Time. Up Time and Remarks) in JFTOC 
SITREP. Tracking Log. 


Process 3.4, Generate As-occurring SITREP - JFTOC data flows are 
described as follows: 


e JFTOC uses SITREP Information to generate As-occurring SITREP for 
outages listed in FOTP. 


e JFTOC sends electronic copy of As-occurring SITREP to operational 
commanders. NCTC and CINCPACEFLT in accordance with NCTAMS BR 
regulating Timing of Initial As-occurring STTREP. 
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e JFTOC files paper copy of As-occurring SITREP in JFTOC As-occurring 
SITREP Folder. 


Process 3.5, Notify NCTAMS Chain-of-Command - JFTOC data flows 


are described as follows: 


e In accordance with NCTAMS BR regulating Criteria for Chain-of-Command 
Notification, JFTOC initiates process of notifying NCTAMS chain-of- 
command. 


e JFTOC retrieves Outage Info from JFTOC Station Log. 


e JFTOC notifies NCTAMS Chain-of-Command of outage via telephone as 
required by SOPs. 


e JFTOC places Record of Notification in JFTOC Station Log that notification 
occurred. 


d. Troubleshoot Outage 
Figure 4.10 shows the Baseline FMS Process Four, Level One Diagram. 
Process 4.1, Perform Troubleshooting (TS) Actions - Division data flows 


are described as follows: 


e Process four is initiated upon receipt of Confirmed Outage Report (from 
process one). 


e TS actions are influenced by NCTAMS TS Priorities which are established in 
Process Nine. 


e Division and Customer (or Regional NCTS) communicate frequently via 
orderwire or phone, TS Status Query/TS Status Response, to obtain 
information about what the other side “sees” as troubleshooting steps are 
performed. 


e Information exchanged via orderwire, TS Entries, is stored electronically in 
Division Orderwire Files. 


e Information obtained via phone, Troubleshooting Notes, is written on Division 
W'S Note Pad. 
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e Recalled TS Orderwire Entries and Recalled TS Notes are retrieved to make 
electronic entry in Division Station Log, TS Updates, to document 
troubleshooting progress. 


e During TS process, Division may receive a CASREP from a ship or NCTS 
documenting failed communications equipment and stating impact on 
unit/station’s ability to meet its mission. 


e CASREP Info 1s recorded electronically in Div Station Log. 


e Division passes troubleshooting status to JFTOC via phone or orderwire. 
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Figure 4.10. Process Four: Troubleshoot Outage. 
Process 4.2. Report TS Actions - JFTOC data flows are described as 
follows: 


e JFTOC receives Troubleshooting Status passed from Division. 


e TS reporting is influenced by NCTAMS TS Priorities which are established in 
Process Nine, Formulate NCTAMS Trouble Management Strategy. 
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e Information passed from Division or Customer/NCTS via orderwire, TS 
Entries, is stored in JFTOC OW Files. 


e Information passed from Division or Customer/NCTS via phone, TS Notes, is 
stored on JFTOC JWO Note Pad. 


e JFTOC makes electronic entry in JFTOC Station Log, TS Updates, 
documenting troubleshooting status. 


e Recalled TS Entries and Recalled TS Notes from JFTOC Orderwire File and 
JFTOC JWO Note Pad are used to draft reply to outage notification. 


e JFTOC sends NCTAMS COMSPOT Reply in response to COMSPOT received 
from Customer or Regional NCTS. 


e JFTOC receives Follow-Up Outage Report from Customer or Regional NCTS 
via COMSPOT, orderwire or phone. 


e COMSPOTs received from Customer are stored in JFTOC COMSPOT Folder. 

e During TS Reporting, JFTOC may receive a CASREP from a ship or NCTS 
documenting failed communications equipment and stating impact on 
unit/station’s ability to meet its mission. 


e CASREP Info is recorded electronically in JFTOC Station Log. 


e Based upon information in customer follow-up report and CASREP (if 
applicable), a requirement for an Updated SITREP is created. 


e. Track and Update SITREP/As-occurring SITREP 

Figure 4.11 shows the Baseline FMS Process Five, Level One Diagram. 

Process 5.1, Determine if SITREP Requires Update - JFTOC data flows 
are described as follows: 


e Process Five 1s initiated either when information received in a Customer 
Follow-Up Outage Report suggests a SITREP update is appropriate or when a 
SITREP exceeds its ETR. 


e JFTOC manually checks JFTOC SITREP Tracking Log. ETR Status Check, to 
see if SITREP has exceeded its ETR. 


e When SITREP update 1s required. JFTOC sends a SITREP Update Request to 
Division via phone or orderwire. 
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Figure 4.11. Process Five: Track and Update SITREP/As-occurring SITREP. 
Process 5.2, Update Customer/NCTS Status - Division data flows are 
described as follows: 


e Division receives SITREP Update Request. 


e Division sends an Outage Status Query to Customer/NCTS via orderwire or 
phone. 


e [Division receives Outage Status Response from Customer/NCTS via orderwire 
or phone. 


e Outage Status Orderwire Entry 1s obtained via orderwire and stored 
electronically in Division Orderwire File. 


e Outage Status Notes are obtained via phone and stored manually on Division 
WS Note Pad. 


e Division retrieves Outage Status Notes and Orderwire Entry stored on Division 
WS Note Pad and Division Orderwire Files, respectively. 
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Process 5.3, Generate Updated SITREP - Division data flows are 
described as follows: 


e Division records Updated Customer/NCTS Outage Status in Division Station 
Log. 


e Division retrieves Updated NCTAMS Outage Status from Division Station 
Log. 


e Division generates Updated SITREP. 
e Division stores paper copy of SITREP in Div SITREP Folder. 


e Division sends Updated SITREP to JFTOC electronically via orderwire or 
manually via messenger. 


Process 5.4, Record Updated SITREP - JFTOC data flows are described 
as follows: 
e JFTOC receives Updated SITREP. 
e JFTOC manually files Updated SITREP in JFTOC SITREP Folder. 
e JFTOC records Updated SITREP Info in JFTOC Station Log. 


e JFTOC records Updated SITREP Tracking Info in JFTOC SITREP Tracking 
Log. 


Process 5.5, Generate Updated As-occurring SITREP - JFTOC data flows 


are described as follows: 


e JFTOC uses Updated SITREP Information to generate Updated As-occurring 
STPREP: 


e JF TOC sends electronic copy of Updated As-occurring SITREP to Operational 
Commanders. 


e JFTOC places paper copy of updated As-occurring SITREP in JFTOC As- 
occurring SITREP Folder. 


f. Generate Reports 


Figure 4.12 shows the Baseline FMS Process Six, Level One Diagram. 
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Figure 4.12. Process Six: Generate Reports. 


Process 6.1, Generate Reports - JFTOC data flows are described as 


follows: 


e JFTOC performs process in accordance with NCTAMS BR regulating DSR 
Reporting Criteria and Timing. 


e JFTOC retrieves Outage Info from JFTOC Station Log, JFTOC SITREP 
Folder and JFTOC COMSPOT Folder to compose the DSR for Operational 
Commanders as specified in FOTP. 


e JFTOC sends electronic copy of DSR to operational commanders. 


e JFTOC makes paper copy of DSR for use by Division Officers and Department 
Head in Process Nine, Formulate NCTAMS Trouble Management Strategy. 


e JF TOC places paper copy of DSR in Operational Commander's Report 
Archive. 
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Process 6.2, Generate Reports - Division data flows are described as 


follows: 


e Division performs process in accordance with NCTAMS Division Reporting 
Criteria and Timing. 


e Division retrieves Outage Information from Div Station Log, Div SITREP 
Folder and Div COMSPOT Folder to generate Division Morning Report. 


e Division Morning Report is used by Division Officers in performing Process 
Nine, Formulate NCTAMS Trouble Management Strategy. 


e At the end of the day, Division Officers disposes of Division Morning Report 
in accordance with destruction of classified material directives. 


Z. Close-out Records Upon Resolution 


Figure 4.13 shows the Baseline FMS Process Seven, Level One Diagram. 
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Figure 4.13. Process Seven: Close-out Records Upon Resolution. 
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Process 7.1, Generate Final SITREP & Record Info - Division data flows 


are described as follows: 


e Process Seven is initiated when Division receives final COMSPOT and 
CASREP (where applicable) from Customer/NCTS. 


e Division uses final COMSPOT and CASREP to generate final SITREP. 


e Division places paper copy of Final COMSPOT in Division COMSPOT 
Folder. 


e Division places paper copy of Final SITREP in Division SITREP Folder. 


e Division makes Final Log Entry, including final CASREP info, in Division 
Station Log. 


e Division stores Final Orderwire Entries in Division Orderwire File. 


e Division sends Final SITREP to JFTOC electronically via orderwire or 
manually via messenger. 


Process 7.2, Generate Final As-occurring SITREP & Record Info - 


JFTOC data flows are described as follows: 


e JFTOC receives final SITREP from Division. 


e JFTOC receives Final COMSPOT and CASREP (where applicable) from 
Customer/NCTS. 


e JFTOC uses Final SITREP information to manually record close-out 
information in JFTOC SITREP Tracking Log. 


e JFTOC uses Final SITREP information to generate final As-occurring SITREP. 


e JFTOC sends electronic copy of As-occurring SITREP to Operational 
Commanders. 


e JFTOC places paper copy of Final COMSPOT in JFTOC COMSPOT Folder. 
e JFTOC places paper copy of Final SITREP in JFTOC SITREP Folder. 


e JFTOC places paper copy of Final As-occurring SITREP in JFTOC As- 
occurring SITREP Folder. 
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e JFTOC makes Final Station Log Entry, including Final CASREP Info, in 
JFTOC Station Log. 


e JFTOC stores Final Orderwire Entry in JFTOC Orderwire File. 
Process 7.3, Archive Outage Records - Division data flows are described 


as follows: 


e Division removes COMSPOTs from Division COMSPOT Folder at the end of 
each watch that are no longer being used and disposes of them in accordance 
with destruction of classified material directives. 


e Division periodically removes SITREPs from Division SITREP Folder and 
saves electronic copy to disk, creating Division SITREP Archive. After one 
year, archived SITREPs are deleted. 


e Division prints a copy of the Division Station Log and manually files it in 
Division Station Log Archive by RADAY. After one year, archived Division 
Station Logs are destroyed. 


e Division closes out the orderwire at the end of each RADAY and saves an 
electronic copy to Division Orderwire Archive disk. After one month, archived 
Division Orderwire Files are overwritten by the next month’s file. 


Process 7.4, Archive Outage Records - JFTOC data flows are described 


as follows: 


e JFTOC periodically removes COMSPOTs from JFTOC COMSPOT Folder 
and manually files them in JFTOC COMSPOT Archive by Date-Time-Group 
(DTG) order. After 30 days, archived COMSPOTs are destroyed. 


e JFTOC periodically removes SITREPs from JFTOC SITREP Folder and 
manually files them in JFTOC SITREP Archive by SITREP number. After 30 
days. archived SITREPs are destroyed. 


e JFTOC periodically removes SITREPs from JFTOC As-occurring SITREP 
Folder and manually files them in JFTOC As-occurring SITREP Archive by 
SITREP number. After 30 days, archived As-occurring SITREPs are 
destroved. 


e JFTOC prints a copy of the JFTOC Station Log and manually files it in JFTOC 


Station Log Archive by RADAY. After one year, archived JFTOC Station 
Logs are destroyed. 
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e JFTOC closes out the orderwire at the end of each RADAY and saves an 
electronic copy to JFTOC Orderwire Archive disk. After one month, archived 
JFTOC Orderwire Files are overwritten by the next month’s file. 


A. Produce DOR 


Figure 4.14 shows the Baseline FMS Process Eight, Level One Diagram. 
Process 8.1, Request DOR Input - JFTOC 


e Process Eight is initiated when JFTOC receives a request from a Customer for 
a DOR. 


e JFTOC tasks Division to generate a DOR input. 
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Figure 4.14. Process Eight: Produce Detailed Outage Report. 
Process 8.2, Generate DOR Input - Division Figure 4.12 shows the 
Baseline FMS Process Six, Level One Diagram. 


e Division manually retrieves outage information from each of the following: 
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e Division SITREP Archive 
e Division Station Log Archive 
e Division Orderwire Archive 
e Division manually sorts through retrieved outage information and constructs a 
time line of events from Division’s point of view. Time line will be Division 


DOR input. 


e Division places electronic copy of Division DOR input on disk and manually 
forwards it to JFTOC. 


Process 8.3, Consolidate and Finalize DOR - JFTOC Figure 4.12 shows 
the Baseline FMS Process Six, Level One Diagram. 
e JFTOC receives Division DOR input. 
e JFTOC manually retrieves outage information from each of the following: 
e JFTOC COMSPOT Archive 
e JFTOC SITREP Archive 
e JFTOC Station Log Archive 
e JFTOC Orderwire Archive 
e JFTOC As-occurring SITREP Archive 


e JFTOC manually sorts through retrieved outage information and constructs a 
time line of events from JFTOC point of view. 


e JFTOC compares JFTOC time line with Division time line. 


e JF TOC combines time lines, eliminating entries as necessary to create the most 
complete and accurate version of events that transpired during the outage. 


e JFTOC transmits electronic copy of DOR via naval message. 


A. Formulate Management Strategy 
Process 9, Formulate Management Strategy, data flows are described as 


follows: 
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e Process Nine is initiated based upon the NCTAMS Conduct of Operations 
Briefs to formulate management strategy. 


e NCTAMS managers receive Operational Commander's TS Priorities via phone, 
e-mail, or meetings. 


e NCTAMS managers review Daily COMSPOTs and DSR/Division Morning 
Report (from process Six). 


e Process Nine produces NCTAMS TS Priorities which are an input into Process 
Four, Troubleshoot Outage. 


D. FMS SYSTEM PHYSICAL CHARACTERISTICS 
ie N3, Excluding NOC 
The NOC Division is not included in this discussion of system physical 
characteristics; it will be covered separately in the next sub-section. 
a. Network 
The nine processes which comprise the Baseline FMS are performed in 
each N3 division using a combination of stand-alone PCs, PCs connected via an in- 
house orderwire and manual processes (e.g., recording information in a log book). The 
in-house orderwire operates as a coordination or “chat” circuit with certain divisions 
available via different ports. Previous entries may be reviewed by scrolling back to the 
desired time period. Files are saved periodically to diskette. FMS processes are 
categorized below as using stand-alone PCs, in-house orderwire or manual. 
e Receive Notification: Stand-alone PC 
e Log Outage: Stand-alone PC 
e Create SITREP/As-occurring SITREP: 
e Create: stand-alone PC 


e Forward to JFTOC: In-house orderwire. 
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e Troubleshoot Outage: In-house orderwire 
e Track & Update SITREP/As-occurring SITREP: 
e Track: Manual 
e Update: Stand-alone PC 
e Forward to JFTOC: In-house orderwire 
e Generate Reports: Stand-alone PC 
e Close-out Records Upon Resolution: Stand-alone PC/Manual 
e Produce DOR: Stand-alone PC 
e Formulate NCTAMS Trouble Management Strategy: Stand-alone PC/Manual 


b. Hardware 


Computers include a mixture of IBM clones using Intel 386 and 486 
microprocessors. 
C. Software 
The following software is used in the baseline FMS: 
e PC Operating System: DOS (mixture of versions) 
e Station Logs: Radio Log 5.31 (DOS based, in-house developed) 
e SITREP/As-occurring SITREP: DOS Editor/Wordperfect 
e DSR: Wordperfect 


d. Data Storage 


Reiterating the information provided in Table 4.2., Baseline FMS data 
stores are a combination of the following: 
e Paper File 


e Electronic Flat File 
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2: NOC 


A. NOC Background 


Officially established August 1, 1996, the PRNOC “provides Pacific area 
commands with seamless access to classified and unclassified information services via 
Internet protocol (IP) networks.” [Ref. 34] A full range of network management 
services are provided for both the NIPRNet and SIPRNet. Because the PRNOC was just 
recently stood-up and serves as an IP network service provider, it utilizes fault 
management technology comparable to a commercial NOC. 

b. Network 

A Windows NT 4.0, Ethernet LAN, run over optical fiber, provides 
network services within the NOC. 


c. Hardware 

Hardware used by the NOC includes: 
e HP TAC IV Workstations 
e Sun Ultra Workstations 
e Sun Sparc Workstations 
e CISCO 4000 and 7000 series routers 

d. Software 

Software used by the NOC includes: 
e NMS: Cabletron Spectrum 


e Help Desk Application: Remedy AR System 3.0 with UNIX flat files for 
database support and configured for automatic trouble ticket generation. 


The implementation of a NMS and help desk application in the NOC 


created a paradigm shift within N3. Through use of the help desk application, AR 
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System, and its Web interface, AR Web, the NOC generates/receives three different 
types of trouble tickets: (1) tickets generated by fleet units using the Web interface via a 
SIPRNet Web homepage, (2) tickets created from the NMS, or (3) tickets generated 
manually by NOC personnel. Since trouble tickets contain a record of all actions taken 
to resolve an outage, NOC personnel soon realized that creating a trouble ticket, 
generating a SITREP, and making a station log entry creates three copies of the same 
information. Division officer/department head discussions regarding this duplicated 
effort agreed that the NOC could submit trouble tickets to the JFTOC instead of 


SEs: 


E. CLASSIFIED LAN IMPLEMENTATION 

il Background 

Information regarding NCTAMS EASTPAC’s classified LAN implementation 
was provided via telephone interview with the NCTAMS EASTPAC Maintenance 
Division Officer who is currently managing the project. The command is in the process 
of installing a classified LAN to facilitate communication between N3 divisions, 
between N3 and the CO/XO (who are located in a different building), and with external 
entities. Examples of future use include: classified message traffic dissemination (e.g., 
COMSPOTs). internal classified e-mail connectivity, and external e-mail capability via 
the SIPRNet. The target completion date for implementation in N3°s building is August 
1997. Connectivity to the CO/XO's building will require installation of an National 
security. Agency (NSA) approved encryption device. CO/XO connection to the 


Classified network has a target date of September 1997. 
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Ze Design 

Classified LAN design is planned as follows: 

e Cable Plant Technology: Optical Fiber 

e Physical Plant Architecture: Star wired to a single server. 
e Data Link Technology: Ethernet 

e Architecture: Client/server 

e Server: Centralized 

Se Hardware 


Classified LAN hardware is planned as follows: 


e Server: One (1) low end server (P 166, (2) 2.1 GB SCSI hard drives, 64 MB 
RAM) 


e Clients: Ten (10) (P166, 2.1 GB IDE removable hard drive, 32 MB RAM) 


e Hub: 10 Mbps Ethernet (Low speed hub chosen due to small number of client 
machines and cost constraint.) 


e Existing Hardware: SIPRNet router to be connected to server using fiber run. 
4. Software 


Classified LAN software is planned as follows: 
e NOS: Windows NT 4.0 

e E-mail: MS Exchange 

e Office Automation: MS Office 

e Web Browser: MS Explorer 


e AUTODIN Message Dissemination: Message Dissemination Subsystem 


(MDS) 
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5: Physical Configuration 
Classified LAN physical configuration is planned as follows: 
e Location of Server: JFTOC 
e Location of Nine (9) Client Machines: 
e N3 Front Office 
e Tech Control Deck 
e Message Services Admin 
e Message Services Deck (for classified message traffic upload) 
e NOC Admin 
e Maintenance Division 
o JFTOG Deck 
e JFTOC Admin Office 
e CO/XO 
6. Administration 
Classified LAN physical configuration is planned as follows: 
e Network administration will be performed by NOC personnel. 


e Users of each workstation will be determined by the appropriate department 
head/division officer based upon security clearance and need to know. 


Ee SUMMARY 

The Baseline FMS 1s essentially a manual, non-networked system dominated by 
electronic flat file and paper data stores. Its processes produce identifiable output in the 
form of reports such as the DSR, DOR, and COMSPOT. The implementation of 
automated fault management tools in the NOC and installation of a classified network 


within N3 suggest types of technology that might be part of a target architecture. 
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VV. DETERMINING THE TARGET SYSTEM 


A. INTRODUCTION 

This chapter covers the fourth step of the TAFIM process, Determining the Target 
System. Chapter IV established the character and state of the Baseline System as 
essentially manual with stand-alone components. To describe the desired system, first, a 
goal architecture is presented through the use of a vision statement, objectives, and macro 
architecture. Second, problem constraints are discussed and quantified. Next, the Target 
System is examined, and its association with Business Process Reengineering (BPR) 
principles is explored. Finally, required capabilities of a help desk application in the 


target system is introduced. 


B. GOAL ARCHITECTURE OVERVIEW 

1. Vision 

A vision is a broad statement that states the qualitative goals for the system at 
some point over the horizon. [Ref. 62:p. 3] In formulating a system vision, an 
Organization must ask, ““What do we want the system to look like in “X” number of 
years?” Due to the rapidly evolving nature of information technology in general, and the 
help desk software market in particular, the author defined “X” as three years. 
Additionally, the organization must ask, “Does the system's vision support the vision and 
doctrine of the organization as a whole?” Figure 5.1 shows a system vision statement 
developed from establishing the problem framework. defining the system problem, and 


assessing the baseline system. The vision must be reviewed periodically during the target 
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system determination step to ensure that actions remain true to this over-arching goal. 


[Ref. 62:p.3] 


TARGET SYSTEM VISION STATEMENT 


In order to meet the United States Navy’s demanding information needs of the 
21* century, the JFTOC, the hub of telecommunications management for each 
region, requires an effective fault management system. This information system 


must provide troubleshooting, coordination and fault resolution information to 
both providers and users of NCTC information services. Data flows and formats 
should not require specialized user training. Ultimately, the system must integrate 
with a network management system that provides centralized, integrated and 
secure management of all information systems, regardless of platform or protocol. 





Figure 5.1. Target System Vision Statement. 
Ze Objectives 
Objectives are the broad goals that the system must achieve to be productive. 
[Ref.62:p. 12] Figure 5.2 displays objectives for the target system. These qualitative 
aims are drawn largely from the vision statement, above, and from DOD doctrine and 


policy discussed in Chapter II. 






TARGET SYSTEM OBJECTIVES 













Primary Objective: 
To provide a centralized and accessible source of near real-time fault management 
information for providers and users of NCTC information services. 






Secondary Objectives: 
- To demonstrate to customers that positive action is underway to correct faults 
and restore information Services. 

- To facilitate information exchange between NCTAMS and customer personnel 
about actions taken toward diagnosing and correcting faults. 

- To enable automated selective retrieval of fault management information. 

- To integrate log keeping functions performed by each NCTAMS operations 
work center. 

- To allow performance trend analysis to identify systemic problems. 


Figure 5.2. Target System Objectives. 
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ay Macro Architecture 
The macro architecture is an arrangement of the elements or components that 
comprise the target system and their interaction. [Ref. 62:p. 9] Figure 5.3 shows a macro 


architecture for the Target FMS. 
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Figure 5.3. FMS Macro Architecture. [Ref. 40:p. 10] 
a. Subject 
The subject is the information system that the network monitoring element 
watches. A cross-section of the telecommunications services currently monitored by a 
NCTAMS includes: RF links (e.g.. EHF, SHF, UHF), IP network services (e.g., SIPRNet, 
NIPRNet). messaging services (¢.g.. NAVCOMPARS, CUDIXS, VERDIN/Integrated 
Submarine Automated Broadcast Processing System (ISABPS), voice services (c.g.. 


Plain Old Telephone Services (POTS)), and video teleconferencing services (Video 


TS 


Information Exchange System (VIXS)). Telecommunications services of the immediate 
future would also include: DMS, DISN End-User Services, and integrated Defense 
Information Infrastructure (DI) services. 


b. Network Monitoring 


The network monitoring element uses C4I architecture to query 
management agents in individual devices, such as routers and bridges. Responses are 
compared against the alarm elements’ established alarm activation thresholds to 
determine if alarm generation is required. After each query, the network monitoring 
element updates a configuration database which stores information about the status of 
each subject. Additionally, the network monitoring element provides updates to a 
performance database which tracks overall utilization of network resources. [Ref. 24:p. 
553) 

c. Management Display 

The management display element gives a representation of the network’s 
configuration, the status of all network elements (subjects), and information received 
from the fault detection element. The display must be user-friendly and allow operations 
center personnel to “drill-down” to obtain greater detail on a specific network 
component. [Ref. 24:p. 553] 


d. Alarm Element 


The alarm element uses the polling information generated by the network 
monitoring element and compares that data against defined, alarm thresholds to 
determine if generation is required. If an alarm is generated, the system must process the 


alarm which may include automatic trouble ticket generation, notification of operations 
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center via paper or other actions. Alarm processing may also include fault severity level 
classification using categories such as minor/major/critical or class 1/class 2/class 3. [Ref. 
24:p. 553] 

é. Event Log/Trouble Ticket 

Event logging occurs when an abnormal condition (e.g., outage or 
degradation of service) is reported. Logging may be initiated as a result of: (1) alarm 
element (automatic generation), (2) customer notification via the C4I architecture, or (3) 
Operations center personnel action using a network monitoring element. Once the 
problem is determined to be legitimate, the trouble ticket is opened. Trouble tickets are 
retained in the trouble ticket database for performance analysis and report generation. 
Because the event log consists of data base records, reports may be generated on specific 
faults or for specific periods of time (e.g., a 24-hour period). [Ref. 24:p. 553] 


i Remote Diagnosis 


The remote diagnosis element attempts to identify the cause of the fault 
using information from the configuration database and from tests performed via the 
network monitoring element. If a diagnosis is made, it is displayed to operations center 
personnel via the management display. If fault correction is achieved, diagnostic 
information should be documented in the event log/trouble ticket. The boundaries of the 
network monitoring system may prevent a remote diagnosis. If this is the case, other 
elements of the C41 architecture will be used to diagnose and correct the fault. [Ref. 24:p. 


553] 
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g- Security 


The security element controls access to services and resources via the 
network management system. Security management tasks may include: authenticating 
network management system users, preventing outside users from accessing certain 
network management services, and auditing access of network resources and services for 
evaluation of security policies. [Ref. 24:p. 553] 

A. C4I Architecture 

The C4I architecture, DISN, is the backbone which connects each 
information system (subject). The network monitoring and remote diagnosis elements 
function via this architecture. In addition, DISN is used for communication and 
coordination between operations center and user personnel who manage the network. 


L Operations Center 


The Operations Center hosts the people who manage the C4I resources 
and who interact with the users of those resources. They utilize the network monitoring, 
management display, alarm element, event log/trouble ticket, remote diagnosis and 


security elements to manage the network. 


Cc. TARGET SYSTEM PROBLEM FORMULATION MODEL 

Chapter III introduced a formulation model that incorporated the basic criterion 
and constraints that will be used to solve the problem. That template, presented as Figure 
3.6, provided four types of constraints: system quality, information quality. technology, 
and existing information infrastructure. 

In this section, specific constraints within each category are presented, and where 


appropriate, values are quantified based upon responses to a questionnaire completed by 
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a group of NCTAMS EASTPAC users. Based upon only 13 responses, these values are 
not statistically significant, but they illustrate a valid methodology for obtaining such 
quantities. The questionnaire included 19 multiple choice questions about different 
aspects of system and information quality. Questionnaires were completed by N3 
personnel in the following billets or positions: Department Head, Division Officers, and 
JFTOC JWOs. The author’s experience of working at a NCTAMS was used as a 
“reasonableness” check to questionnaire responses; it 1s noted below where the author 
disagrees with survey responses. Figure 5.4 shows the Detailed Problem Formulation. 
1. System Quality 


A. Availability 


Availability is a measure of the degree to which a system is “in an 
operable and committable state at the start of an (operation) when that (operation) is 
called for at a random time.” It is calculated by dividing Mean Time Between Failure 
(MTBF) by the sum of MBTF and Mean Time To Repair (MTTR). [Ref. 19] Seventy- 
seven percent of responses indicated that availability needs to be greater than or equal to 
95 percent (or available 57 out of every 60 minutes). 


b. Response Time 


Response Time is a measure of the time it takes for the system to respond 
to user commands. Ninety-two percent of responses indicated that response time 


needs to be less than or equal to five seconds. 
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MINIMIZE SYSTEM COST (Over Its Life Cycle) 
Subject To 


(1) System Quality 
Availability >= 95% 
Response Time <= 5 seconds 
Data Import Speed <= 30 minutes 
Data Export Speed <= 10 seconds 
User Interface Assistance = Input screens provide choice of proper entry or example. 
Ease of Use = User must be proficient and comfortable with Windows and Web browsers. 
Input Source Identification = System automatically records and displays Zulu time and 
operator’s initials for each entry. 
Information Pull/Report Generation = System produces SITREPs, logs, statistics and on 
demand responses from user queries. 
Information Access Privileges = System assigns privileges by group and individual user. 
Information Views = System provides capability to limit which fields can be viewed by 
personnel outside the command. 
Security = Sufficient security is provided by SIPRNet Web page which allows access to 
authorized users who perform correct login and password sequence. 
Scalability >= 30 users per NCTAMS 
Desktop Network Access = Users must have access to classified LAN at their work station. 
Training Support = Contractors perform a minimum of eight hours on-site training for all 
operators. 
Maintenance Support = Maintenance provided by qualified maintenance department watch 
stander in each section. (Author Caveat: also need vendor support contract.) 


(2) Information Quality 
Information Timeliness (time between updates) <= 30 minutes 
Information Relevance = System includes outage information including cause of outage and 
estimated time to repair. (Author Caveat: Add latest corrective action taken.) 


(3) Technology 
Help Desk Software 
Other Hardware and Software 


(4) Existing Information Infrastructure/Policy 
DISN 
Classified LAN 
NMS 
COTS Usage 
1T-21 AIS Standards 


Figure 5.4. Detailed Problem Formulation. 
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= Data Import Speed 


This a measure of the rate at which data are entered into the system once 
received. One hundred percent of responses indicated that data import speed needs to be 
less than or equal to 30 minutes. 


d. Data Export Speed 


This refers to the rate at which data is retrieved from the system once a 
command is executed. Seventy-seven percent of responses indicated that data export 
speed needs to be less than or equal to 10 seconds. 


e. User Interface Assistance 


User interface assistance connotes the level of help that the user interface 
provides to ensure that appropriate data are entered in each field. One hundred percent of 
responses indicated that input screens need to provide a choice of proper entries or 
examples. 

f. Ease of Use 

This constraint refers to the level of user computer proficiency required to 
Operate the system. Eighty-five percent indicated that users need to be comfortable with 


using Windows and WWW browser applications. 


L- Input Source Identification 


This refers to the information that the system automatically records and 
displays for each log‘trouble ucket entry. One hundred percent of the respondents 
indicated zulu time must be included and 77 percent indicated that they would also like to 


see the operator's initials recorded. 
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A. Information Pull/Report Generation 


This constraint refers to the type of reports that the system produces on - 
demand. Eighty-five percent indicated they would like SITREPs, logs, statistics, and 
response to user queries to be available on demand. 

L Information Access Privileges 

Information access privileges refers to the level at which the system 
assigns and enforces read, write, and other user privileges. Ninety-two percent of 
responses indicated assignment of privileges at the group and individual level. 


J. Information Views 


Information views refers to the ability of the system to produce different 
“snap-shots” of data for different users. Seventy-seven percent of responses were either 
neutral or agreed that the system needs to limit which fields are viewable by personnel 
outside the command. 

k. Security 

This constraint refers to type of security required to protect the system 
from unauthorized access. Sixty-two percent of respondents indicated that sufficient 
security 1s provided by a SIPRNet Web page that allows access by authorized users who 
perform a correct login and password sequence. 

i Scalability 

Scalability refers to the ability of the system to “grow” to accommodate 
additional users, hardware, or software either co-located or globally distributed from the 
Original system configuration. One hundred percent of respondents indicated that all N3 


Watch Supervisors are potential system users. Other potential users recognized by 
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respondents included: N3 Department Head and Divos (92%), N3 Leading Chief Petty 
Officers (LCPOs) (85%), CO/XO (54%), and all N3 watch standers (54%). Based upon 
the author’s understanding of NCTAMS operations and discussion with senior N3 
leaders, the author believes the system must support at least 30 workstations/30 users at 
each NCTAMS. The scalability of the system must also support up to 1000 users as the 
system expands to the Area IMSC level. This estimate is based on 30 users at 24 sites (3 
NCTAMS, 15 NCTSs, 3 NCTAMS DETs, and 3 NAVCOMTELDETSs) plus a rounding 
factor to allow for growth. [Ref. 30:p. 3-1] 

m. Desktop Access 

Desktop Access refers to the ability of a user to access the system, via a 
classified LAN, from a desktop PC or workstation. Ninety-two percent of responses 
indicated that users of the system must have desktop access. 

Nn. Training Support 

This constraint concerns the type and location of training that accompanies 
system implementation. Sixty-one percent of respondents selected on-site, contractor- 
conducted training for all operators as their number one training choice. The next most 
popular option, contractor conducted on-site training for trainers only. was ranked 
number one by only 23 percent of respondents. Seventy-seven percent of responses 
indicated a need for at least one full day of training. 

0. Maintenance Support 

Maintenance refers to the accessibility and location of maintenance 
personnel. Sixty-two percent of respondents selected having a system qualified 


Maintenance Department (N6) watchstander in each watch section as their number one 
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maintenance choice. The next most popular option, qualified day worker on 24 hour 
recall, received the number one ranking from only 23 percent of respondents. The author 
notes that vendor support would also be required for system problems that are beyond the 
troubleshooting capability of command technicians. 

2: Information Quality 


a. Information Timeliness 


This constraint refers to the maximum time between data updates to 
ensure current information is available to decision-makers. Eighty-five percent of 
responses indicated the need for updates no later than every 30 minutes. 


b. Information Relevance 


JP 6-0 defines information relevance as, “information that applies to the 
mission, task, or situation at hand.” [Ref. 18:p. I-5] The questionnaire asked respondents 
to rank five items in the order of the information most commonly requested by 
customers; two items emerged as dominant responses. Thirty-eight percent of 
respondents selected cause of outage as either their number one or number two choice for 
relevancy. Likewise, 35 percent of respondents selected estimated time of repair as either 
their first or second choice. Although, latest corrective action taken received only eight 
percent of the number one and two rankings, the author believes that this item is of equal 


relevance. 
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3. Technology 


a. Help Desk Software 


The current functionality of help desk technology was reviewed in Chapter 
III]. The capabilities of these applications at the time of target system implementation is a 
constraint. 

b. Other Hardware and Software 

Without going into specific details, the performance capabilities of each 
target system hardware and software component, at the time of implementation, are 
considered a constraint. 

4. Existing Information Infrastructure/Policy 


a DISN 


‘““A sub-element of the DII, the DISN is the DOD’s consolidated world- 
wide enterprise-level telecommunications infrastructure that provides the end-to-end 
information transfer network for supporting military operations.” [Ref. 8:p. 2-1] 
SIPRNet is DISN’s data network for Confidential and Secret information. Use of the 
DISN is one element of the Vision for DOD Information Technology expressed in the 
TAFIM. [Ref. 9) Use of the SIPRNet is, therefore, considered a constraint. 


b. Classified LAN 


An FMS requires a secure network, because outage information about 
afloat units is classified. Since NCTAMS receives classified message traffic daily. a 
secure LAN for DMS organizational and personal e-mail will be a requirement. 
Therefore, an existing classified LAN is considered a constraint. NCTAMS EASTPAC’s 


classified LAN will be used in the next chapter in a migration path illustration. 
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C NMS 


Both the PRNOC at NCTAMS EASTPAC and the Unified Atlantic 
Region Network Operations Center (UARNOC) at NCTAMS LANT, utilize Cabletron 
Spectrum as their NMS. 

d. COTS Usage 

The Federal Acquisition Regulation, TAFIM, and IT-21 strategy all stress 
the use of COTS IT products, whenever, they are available to meet DOD’s IT 
requirements. [Ref. 11, 9 and 4] COTS usage is, therefore, considered a constraint. 


e. IT-21 AIS Standards 


Chapter II contains the IT-21 AIS standards. 


D. TARGET SYSTEM DFD 
It is time to stop paving cow paths. Instead of embedding outdated 
processes in silicon and software, we should obliterate them and start over. 

We should “reengineer’” our business processes in order to achieve 

dramatic improvements in their performance. [Ref. 13:p. 104] 

These words, written by Michael Hammer in his 1990 ground-breaking article, 
“Reengineering Work: Don’t Automate, Obliterate”, introduced the technique of BPR. 
During the past decade, it has become one of the most frequently discussed methods for 
improving Organizational performance. Its popularity “stems from its promise of 
achieving high levels of improvement in cost, quality, and timeliness...” [Ref. 12:p. 12] 

In this section, DFDs for a target system are presented which were developed 
using the guidance of Hammer's Principles of Reengineering. These axioms include 


[Ref. 13:pp. 109-112}: 


e Organize around outcomes, not tasks. 
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e Have those who use the output of the process perform the process. 

e Treat geographically dispersed resources as though they were centralized. 

e Link parallel activities instead of integrating their results. 

e Capture information once and at the source. 

Although this target system was developed using BPR axioms, the redesign did 
not use the method espoused by both Hammer and Gerald Hoffman; use of a team who 
understands the entire process from many different points of view. [Ref. 13:p. 108],[Ref. 
17:p. 84] Without the insight of team members, the author’s intention is to provide one 
possible option for a reengineered target system. 

i. Level Zero Diagram 

Figures 5.5 and 5.6 show the Target System Level One Diagram. The following 
discussion provides insight into the methodology used to model the Target System. A 
detailed description of each process will be provided in the next subsection with each 
Level One Diagram. 

4. Processes 

The nine Baseline System processes are reduced to seven in the Target 
System. Baseline System Processes Two and Three are combined into a single Target 
System Process Two. Instead of making a log entry to a stand-alone file, outage 
information is recorded to the trouble ticket, i.e. capturing information once at the source. 
Similarly. Baseline System Process Five is eliminated through the replacement of paper 


SITREPs with continuously updated trouble tickets. 
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TARGET SYSTEM 
LEVEL ZERO DIAGRAM 
PROCESSES 1-3 


Business Rule 


Business Rule 
Confirmed COMSPOT Retrieved COMSPOT 


j j Report As-occurting Report 
Operational 
Confirmed Report /TT from phone, Web or NMS Cdrs 
Division Assigned TT 
System Generated 


As-occurring Report 
System Generated Page 


TT 
Acknowledgment 


Recalled TS Status Info 


for Action 
NCTAMS TS Pnonrties joe Outage Database 
CASREP Text 


| NCTAMS/Customer 
COMSPOT Text 
| CTAMS/Customer Retieved COMSPOT 
Retneved CASREP 
Trouble- Follow-up 
R 
Outage — 


CASREP 
System Required Capabilites 


CASREP |p. DA: Data Access 
Customer | NCTAMS 
; comsPoT | COMSPOT OM. Data Modeling 


Follow-up | Response RD&G. Report Design & Generation 
SC: System Configuration 


Customer SM. System Maintenance 


NCTS 
ZI 





Figure 5.5. Target Level One Diagram: Processes 1-3. 


b. External Entities 
The external entities are independent of process redesign, and therefore, 


remain the same. 

Cc. Data Stores 

The most dramatic and significant aspect of process redesign occur in the 
number and nature of data stores. Whereas the Baseline System Level Zero and One 
Diagrams contained 13 and 20 data stores respectively, the Target System Diagrams 
contain only two. This marked reduction of 90 percent in Level One data stores is the 


result of centralizing data storage to a database server and an e-mail file server. 
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TARGET SYSTEM 
hed LEVEL ZERO DIAGRAM 
Operational PROCESSES 4 hg 7 
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Report Operational 
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Business Rule Reports 
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Repert COMSPOTs 


Business Rule 
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Final As- System Generated Final System Generated 
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Commanders Outage Detailed 
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eae S eal al SC: System Configuration 
“7 NCTS 7 SM System Maintenance 


Figure 5.6. Target Level One Diagram: Processes 4-7. 


d. Data Flows 


Data flows will not be individually discussed, however, by comparing the 
Baseline and Target System Level Zero Diagrams, it is apparent that the number of data 
flows between processes and data stores 1s reduced significantly. This reduction results 
from the use of centralized data storage. 
az, Level One Diagrams 
Processes One through Five, shown in Figures 5.5 and 5.6, are exploded into child 
processes to form the Target System Level One Diagrams; these are shown as Figures 5.7 


through 5.11. Accompanying each Level One Diagram is a detailed descnption of each 
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data flow. Processes Six and Seven, shown in Figure 5.6, are not exploded to a Level 
One Diagram, because they do not require further description via sub-processes. 


A. Receive Notification of Outage 


Figure 5.7 shows the Target FMS Process One, Level One Diagram. 


ustomer Trouble 
Outage Tek TARGET PROCESS ONE 


cousror or NMS Vw “RECEIVE NOTIFICATION 
: OF OUTAGE” 


ae 

Ta al EMERONE 
Receive Confirmed COMSPOT 
Notification - 


Confirmed Reportv/TT From - 
JFTOC Phone, Web or NMS 


———__—S—S 


Division 
Generated 
TT 


Request Outage 

for Confirmation 
Outage 

Confirmation 


Make Outage 
Notification/ 
Confirmation - 
Division 
System Required Capabilites 
DA: Allow assignment of fite 
permissions by user 
DOM. Perma schema design to suppor 
raquead reports & stabsbcal analysis 
SC. intertace with NMS & WWW 
COMSPOT 





Figure 5.7. Process One: Receive Notification of Outage. 
Process 1.1, Receive Notification of Outage - JFTOC, data flows are 
described as follows: 
e Process One is initiated when JFTOC receives: 


e Customer Outage Report from: 


e Customer (afloat or ashore unit) via COMSPOT e-mail or phone call to 1- 
800 help desk line. 


e Regional NCTS via e-mail or phone. 
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e Trouble Ticket (TT) from: 

e Customer, Regional NCTS or Division via SIPRNet Web TT. 

e NMS generated trap data that triggers automatic TT generation. 
e Division Generated TT. 


e For Customer and NCTS reported outages, JFTOC sends e-mail to Division to 
request outage confirmation. 


e COMSPOTs received are stored electronically on the E-mail (File) Server. 


Process 1.2, Make Outage Notification/Confirmation - Division, data 
flows are described as follows: 


e Division receives copies of COMSPOTs for information only. Notification via 
phone and TT are received by JFTOC as central “help desk”. 


e Division is notified of outages via internal alarms/monitors or via e-mail from 
JFTOC, Request for Outage Confirmation. 


e When notified via internal alarms/monitors, Division sends Division Generated 
Te 


* Assumption: NCTAMS Business Rule (BR) may require Regional 
NCTSs and Divisions to send e-mail notifying JFTOC of outage within a given number 


of minutes and to follow-up with a TT. This requirement would not fundamentally 
change Process One. 


b. Create Trouble Ticket/As-occurring Report 
Figure 5.8 shows the Target FMS Process Two, Level One Diagram. 
Process 2.1, Create & Assign TT - JFTOC, data flows are described as 


follows: 


e JFTOC uses information from COMSPOT or phone call to generate TT. 
Information input may occur using keyboard or microphone via voice 
recognition software. 


e Or, JFTOC takes TT received from NMS or Customer (via SIPRNet Web page) 
and validates data assignment to all mandatory fields. 


e JFTOC assigns TT action to the appropriate Division. 
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e TT is stored in Outage Database. 


TARGET PROCESS TWO 
“CREATE TT/AS-OCCURRING 
REPORT” 

LEVEL ONE 


Retrieved 
COMSPOT 


Create 


nd/ : 
Confirmed Report(TT From - and/or Receive TT 


Phone, Web or NMS Assign Assignment - 


@ ys Division 


Division 
Assigned 
TT 


System TT Acknowledgment 


Generated 
As-occurring 
Report 


System 
Generated Page 
Page Acknowledgment 


(To Process 3.1) 


Business Rule: 
Business Rule: Chain of Command 


Notification 
As-occurnng 


Reporting Criteria | Generate Notify -<?_{—_§$@ 
As-occurrin 
R 7 g NCTAMS System Required Capabilites 
JFTOC C . v ow assignment OF file 
ommand permissions by user 
JFTOC DM: Permit schema design to support 
required reports & statistical analysis. 
RD&G: Facilitate report design & 
automatic generation based upon 
pre-defined conditions. 
SC: Intertace with e-mail, pagers, 
report writers, WWW & voice recognition 
software. 


As-occurring 
Report 





Figure 5.8. Process Two: Create Trouble Ticket/As-occurring Report. 
Process 2.2, Receive TT Assignment - Division, data flows are described 


as follows: 


e Submission of TT to database generates alarm to Division Supervisor’s work 
stauion. 


e Division receives TT and acknowledges receipt electronically. 
e Acknowledgment of TT (Division Assigned TT) begins Process Three. 
Process 2.3, Generate As-occurring Report - JFTOC, data flows are 


described as follows: 


e In accordance with NCTAMS BR on As-occurring Reporting Criteria, if outage 
type and elapsed time since start match a pre-defined set of conditions, the 
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system automatically generates As-occurring Report for Operational 
Commanders. 


Process 2.4, Notify NCTAMS Chain-of-Command - JFTOC, data flows 


are described as follows: 


e If outage type and elapsed time since start match a pre-defined set of conditions, 
system automatically sends page to designated Chain-of-Command personnel. 


e Paged personnel place phone call to system to acknowledge system generated 
page. 


c. Troubleshoot (TS) Outage 


Figure 5.9 shows the Target FMS Process Three, Level One Diagram. 
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Figure 5.9. Process Three. Troubleshoot Outage. 
Process 3.1. Perform TS Actions - Division, data flows are described as 


follows: 


5 


e Process 3.1 is initiated when Division is assigned TT in Process 2.2. 
e Division recalls outage info by opening TT file from Outage Database. 


e Based on TT status, Division alerts Customer/NCTS via e-mail to access system 
in order to update TS status via SIPRNet Web page. 


e Customer/NCTS accesses system, opens their TT, reads latest NCTAMS TS 
status, and provides their latest TS status. 


e All entries made to TT are written to Outage Database. 
Process 3.2, Report Status of TS Actions - JFTOC, data flows are 
described as follows: 


e Process 3.2 is initiated in accordance with NCTAMS BR on Time Limit for 
Answering COMSPOTs. 


e JFTOC recalls outage info by opening TT file from Outage Database. 


e JFTOC drafts COMPSOT reply using latest TS info found in TT and e-mails to 
Customer. 


e Based upon NCTAMS BR on addition of COMSPOT/CASREFP text to TT, 
JFTOC launches application which copies COMSPOT text to TT file. 


e Likewise, Customer COMSPOT Follow-Up Reports received by the JWO are 
read and copied to TT in accordance with NCTAMS BR. 


e CASREPs received by the JWO are read and copied to TT in accordance with 
NCTAMS BR. 


Process 3.3, Generate Updated As-occurring Report - JFTOC, data flows 
are described as follows: 
e In accordance with NCTAMS BR on As-occurring Reporting Criteria, if outage 
type and elapsed time since start match a pre-defined set of conditions, system 
automatically generates Updated As-occurring Report for Operational 


Commanders. 


d. Generate Reports 


Figure 5.10 shows the Target FMS Process Four, Level One Diagram. 
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Figure 5.10. Process Four. Generate Reports. 
Process 4.1, Generate Reports - JFTOC, data flows are described as 


follows: 


e Process 4.1 is performed in accordance with NCTAMS BR on Operational 
Commander’s Report Criteria. 


e At specified time each day, system automatically generates Operational 
Commander's Report. 


Process 4.2. Generate Reports - Division, data flows are described as 


follows: 


e Process 4.2 1s performed in accordance with NCTAMS BR on NCTAMS 
Report Criteria. 


e At specified time each day, system automatically generates NCTAMS Internal 
Report. 
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sh Resolve Outage 


Figure 5.11 shows the Target FMS Process Five, Level One Diagram. 
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Figure 5.11. Process Five. Resolve Outage. 
Process 5.1, Close-Out Records - JFTOC, data flows are described as 


follows: 


e Process 5.1 is initiated when JFTOC receives Final COMPSPOT and in some 
cases, Final CASREP, from Customer/NCTS via e-mail. 


e In accordance with NCTAMS BR governing addition of COMSPOT/CASREP 
text to TTs, JFTOC launches application which copies COMSPOT text to TT 
file. 

e JFTOC makes any final entries to TT which are written to the Outage Database. 


Process 5.2, Close-Out Records - Division, data flows are described as 


follows: 
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e Division receives copy of Final COMSPOT via e-mail and makes final entries 
to TT which are written to Outage Database. 


Process 5.3, Generate Final As-occurring Report - JFTOC, data flows are 


described as follows: 


e In accordance with NCTAMS BR on Final As Occurring Reporting Criteria, if 
outage type matches a pre-defined set of conditions and TT status is changed to 
closed, system automatically generates Final As-occurring Report for 
Operational Commanders. 

f Produce DOR 
Process 6, Produce DOR, 1s not exploded to level one. because sufficient 
detail is achieved in the level zero diagram, Figure 5.6. Data flows are described as 


follows: 


e Process 6 1S initiated when JFTOC receives a DOR via e-mail from a Customer. 


e JFTOC specifies outage parameters in pre-formatted report query of Outage 
Database. 


e DOR is automatically generated and e-mailed to Customer. 


g- Formulate Management Strategy 


Process 7, Formulate Management Strategy, 1s not exploded to level one, 
because sufficient detail is achieved in the level zero diagram, Figure 5.6. Data flows are 
described as follows: 


e Process Seven is initiated in accordance with the NCTAMS BR on Conduct of 
Operations Briefs. 


e Process Seven also occurs as a result of Operational Commander management 
issues Communicated to NCTAMS via phone or e-mail. 


e Operational Commanders query Outage Database for Trend Analysis (TA) 
information via Web interface. 


e Designated NCTAMS managers query Outage Database for TA information. 
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e Designated NCTAMS managers query Outage Database for active TT 
information. 


e NCTAMS managers review COMSPOT e-mail received as the result of actions 
performed in Process 4. 


e NCTAMS managers review NCTAMS Internal Report produced in Process 4. 
e After reviewing COMPSOT e-mail, NCTAMS Internal Report, TA information 


and active TT status, NCTAMS managers formulate NCTAMS TS Priorities 
and input priorities to Outage Database. 


Ee. REQUIRED CAPABILITIES OF A HELP DESK APPLICATION IN THE 
TARGET SYSTEM 
Based upon the user assessment and help desk technology review performed in 
Chapter III as well as the problem formulation model presented in Section C, certain 
minimum functions are required from a help desk application if used in the Target 
System. The help desk must: 


e Allow expansion of system from a few users at one command to hundreds of 
users distributed around the world. 


e Employ open system architecture to ensure maximum compatibility with 
existing and future hardware and software assets and tools. 


e Integrate with third-party applications to: 


e Initiate trouble tickets automatically by capturing network management events 
and traps. 


e Initiate trouble tickets via e-mail, phone or S]PRNet. 
e Query or receive trouble ticket status using COTS Web browsers. 
e Enable automatic report generation. 


e Provide automatic notification to designated personnel via outage 
management system, e-mail or pager. 


e Customize user-interface through point-and-click. 
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e Provide capability to employ multiple schemata (e.g., trouble tickets, asset 
management, etc.) 


e Control access at the user level. 


e Initiate events based on a set of conditions and action to occur when conditions 
are’ met. 


e Provide graphical display of trend analysis and alert threshold data. 
e Facilitate user key word search of experience/knowledge databases. 
e Manage information service assets. 


e Track modifications/changes made to information service assets. 


Ite HELPDESK ON-LINE INFORMATION SYSTEM (HOLIS) 
ARCHITECTURE 


The author has coined the name HOLIS for the target system. The major 
components of the HOLIS architecture at the LAN and WAN levels are outlined below. 


1. LAN Architecture 


Figure 5.12 is a notional view of the Target System LAN Architecture. Network, 


hardware, and software specifics are provided below. 
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Figure 5.12. Target System LAN Architecture. 
a. Network 
The network may be described as follows: 
e Architecture: Client/server (concurs with IT-21 standards). 


e Standards: ATM backbone and 100 Mbps Fast Ethernet to the desktop (concurs 
with IT-2] standards). 


e NOS: MS NT 4.0 (concurs with IT-21 standards). 
e Certified to process and store classified material. 


e Connectivity to SIPRNet via router. The SIPRNet, a component of DISN, 
serves as the C4] architecture element of the target macro architecture. 


e Workstations conveniently located for appropriate Watch Supervisors, Division 
Officers, Department Heads and CO/XO. 
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i Software 


The software listed below is provided for illustrative purposes only. Due 
to time constraints, the author did not perform analysis to determine which software 
products best satisfy the problem formulation model. Software chosen specifically to 
comply with IT-21 standards are indicated. Notes below provide the author’s rationale 
for inclusion in this illustration. In addition, where applicable, software is related to the 


target system macro architecture. 
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Table 5.1. Target System Software. 


e Server NOS: NT Server 4.0 (concurs with IT-21 standards). 
e Client NOS: MS NT 4.0 Workstation (concurs with IT-21 standards). 


e NMS: Cabletron Spectrum (See note 1). The NMS serves as the network monitoring, 
management display, alarm element, and remote diagnosis elements of the target system 
macro architecture. 


e Help Desk Application (See note 2). The help desk application serves as the event 
log/trouble ticket element of the target system macro architecture. 


e Remedy AR System Server 
e MS SQL Server 

e MS SQL Client 

e Remedy AR System Client 
e Remedy AR Web Server 

e Remedy Flashboards Server 
e Remedy Flashboards Client 


e E-mail: MS Exchange 4.0 (concurs with IT-21 standards). 


e Report Writer Client/Server: MS Word/MS Excel from MS Office 97 Professional (concurs 
with IT-2] standards). 


e Remote Notification: Personal Productivity Tools Etherpage (See note 3). 


e Voice Recognition: Kurzweil Voice for Windows (See note 4). 


Notes: 


Note |: Cabletron Spectrum is used, because it is currently employed by the NCTAMS 
NOCs. 


Note 2: Remedy AR System is used, because it is currently employed by the NCTAMS NOCs 


and it meets the capabilities requirements for a target system help desk application 
defined in Section E above. 


Note 3: Personal Productivity Tools Etherpage is used, because it is integrates with AR 
System. 


Note 4° Kurzweil Voice for Windows is used, because it is considered one of the top 
performing voice recognition packages. A review of four top selling applications 
described it as follows: “Kurzweil Voice for Windows 2.0 offers the best overall 
performance, with a single mode for hands-free operation and voice dictation and a 


very accurate recognition engine. It is also hardware-independent.” [Ref. 47, p. 
550] 
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C: Hardware 

The hardware listed below is also provided for illustrative purposes. 
Chapter If provided the IT-21 standards for network directory and application/file 
servers. The specific use of each server and number required will differ between 
NCTAMS depending on existing LAN hardware. Table 5.2 suggests one possible 
configuration. 


Table 5.2. Target System Hardware. 


e SIPRNet Router: Connects HOLIS to the SIPRNet. Allows fleet customers 
and NCTSs to access the system to submit/query trouble tickets and 
operational commanders to receive/query outage information. 


e NMS Workstation: Hosts the NMS software. 
Servers: All servers host Server NOS software. 


e Firewall: Hosts the firewall software. Provides the security element of the 
target system macro architecture. 


e WWW Server: Hosts Remedy AR Web Server software. 
e Domain Name Server/Mail Server: Hosts E-mail software and e-mail files. 
e File Server: Hosts network files. 


e Application Server: Hosts Remedy AR System/AR Web/Flashboards, MS 
SQL. and Report Writer server software. 


e Remote Access Server: Hosts Remote Notification software. 


e Client Workstations: Hosts the NOS, MS SQL, Remedy AR System, 
Remedy Flashboards, Report Writer, and Voice Recognition client software. 





2 WAN Architecture 


Figure 5.13 shows the Target System WAN Architecture. Individual components 


were discussed in Subsection one above. 
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Figure 5.13. Target System WAN Architecture. 


G. SUMMARY 
Effective and efficient business processes are central to the success 
of every enterprise. When a company grows significantly or when its 


business or its markets change, it must change its business processes. [Ref. 
17:p. 84} 


This quote from Hoffman basically describes the challenge facing the NCTAMS 
and its FMS. As the role of the NCTAMS JFTOC continues to evolve, it must 
continuously re-examine its business processes. This chapter outlines a target system to 
achieve fault management processes in a more efficient and effective manner. Using the 
problem definition introduced in Chapter II], the Target System was described through a 


series of steps which incrementally established a basic architecture. This architecture 
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will be used in the next chapter to develop a migration path from the baseline to the target 


system. 


105 





VI. DEVELOPING THE MIGRATION PATH CANDIDATES 


A. INTRODUCTION 

The fifth step of the TAFIM process, Developing the Migration Candidates, 
creates several feasible paths for moving from the baseline system, illustrated in Chapter 
IV, to the target architecture, outlined in Chapter V. In order to develop the migration 
paths, first, the Remedy help desk software products are examined in terms of product 
line, functionality, and services offered. Second, the various phase options which 
comprise each migration path are described. Finally, a timeline and cost breakdown are 


established for each migration path option. 


B. REMEDY SOFTWARE 


The Remedy Corporation has experienced rapid growth since its founding in 
1990. Company literature currently reports a total of 3,800 installed sites and a customer 
base that includes a large number of multi-national corporations such as AT&T, 
Motorola, Time Warner, and Wal-Mart. [Ref. 51] 

In terms of a DOD customer base, DISA has employed AR System in a 
significant number of network management centers and as part of several major systems. 
Centers include: Global Operations Security Center (GOSC), the Regional Control 
Centers in the Pacific, Europe and Western Hemisphere (Columbus, Ohio), and Defense 
Mega Centers. Systems include: Global Command and Control System (GCCS), DMS. 
and Joint Defense Information Infrastructure Control System - Deployed (JDIICS-D). 
Discussion with Remedy’s Federal Account Manager also revealed a growing Navy 


client base including: Navy Medical Command, Navy Management Systems Support 
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Office (NavMASSO), Naval Surface Warfare Center (NSWC) Dahlgren, VA and Dam 
Neck, VA, and Bureau of Naval Personnel (BUPERS). [Ref. 47] 

In July 1997, Remedy announced that it will be the first help desk vendor to move 
toward adoption of the DOD COE standard. Remedy will work with Logicon, Inc., a 
government contractor with experience in the COE standard, to develop a COE compliant 
version of their AR System for government customers. [Ref. 47] 

I Products 


a. AR System 


The keystone of the Remedy product line, the AR System, is used to 
automate internal operations including: help desk, asset management, change 
management, and defect tracking. It uses a three-tiered client/server architecture, also 
known as client/server/server. The AR System client serves as the user interface, while 
the AR System workflow engine and DBMS constitute the two server components. AR 
System Server is available in a regular and multi-processing server option (MPSO) which 
allows for more efficient use of server resources. [Ref. 50] 

b. AR Web 

ARWeb is a companion product which allows users of popular Web 
browsers access to the AR System via the Internet. Users are able to enter, query, or 
modify requests without intervention by help desk personnel. It generates Hyper Text 
Markup Language (HTML) forms automatically from an AR System schema, therefore, 
no HTML programming is required. ARWeb is placed behind the firewall and supports 


all of the permissions established by the system administrator, thus making it safe from 
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non-authorized access. Since a Web browser is used as the client, ARWeb operation 
requires only the server component. [Ref. 45] 


c Flashboards 


Another companion product of AR System, Flashboards is coined as “a 
dashboard for driving your business’. [Ref. 52] It provides a visual display of near real- 
time, customizable performance metrics for any data in a AR System schema. Meters 
and graphs use a series of colors to alert managers to changes in performance. Displays 
may be customized to show current performance compared with historical data (e.g., last 
month, last year) to allow trend analysis. Drill-down to more detailed displays or to the 
AR System itself is a system feature. Flashboards uses a client/server architecture. [Ref. 
46] 

D. Functionality 


Tables 6.1, 6.2, and 6.3 provide a summary of AR System functionality. 
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Table 6.1. Remedy AR System General Features. [Ref. 23] 


REMEDY AR SYSTEM FUNCTIONALITY 


GENERAL FEATURES 


Call Management 
Problem Tracking 
Inventory Management 
Training Management 
External Database Links 
Custom Screens 
Windows Client/Server 
UNIX Client/Server 
Macintosh Client 
Messaging 
Import/Export 

API Documented 
Global Modify 

Ad Hoc Query 

Full Query 

Standard Reports 
Custom Reports 
Graphic Reports 
Scanned Images/Pictures 
Password Security 
Screen Level Security 
Field Security 
Chargeback 

Customer Access 
Database Resynchronization 
Keyword Access 
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Table 6.2. Remedy AR System Call Tracking and Problem Management Features. 
(Ref. 23} 


REMEDY AR SYSTEM FUNCTIONALITY 


CALL TRACKING 
Call Log/Track 
Online History 
Caller Configuration 
Resolution Steps Log 
Track Time On Call 
Track Time to Solution 
Track History by Caller 
Track History By Call 
Track History By Equipment 
Match Problem To Expert 
Open Call By E-mail 
Close Call By E-mail 
Track Open Calls 
Track All Actions To Solution 


PROBLEM MANAGEMENT 
Auto Call Escalate 
Priority Levels 
Call Assignment 
Solution Database 
Alen Incoming Call 
Alen Escalation 
Escalation Levels 
Call Linking 
Track Recurring Problems 
System Call Status 
Problem Analy sis Repon 
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Table 6.3. Remedy AR System Problem Resolution, Asset Management, Support 
Focus and Link Features. [Ref. 23] 


REMEDY AR SYSTEM FUNCTIONALITY 


PROBLEM RESOLUTION 
— Keyword Search 
— Full Text Search 


ASSET MANAGEMENT 
— Standard Configurations 
Client Specific Configurations 
Group Level Configurations 
Inventory Tracking 
Repair History 
Purchase Orders 


SUPPORT FOCUS 
— External Support 
— Internal Support 


LINKS 
— World Wide Web 

Lotus Notes 
Network Management 
Asset Management 
E-mail 
Fax/Pager 
Telephony 
External Knowledge Bases 





3. Services 


Remedy also offers a wide range of support services as described below. 


a. Customer Support [Ref. 23] 


Purchase of Customer Support also entitles the customer to all Remedy 
product upgrades at no additional charge. Remedy provides three different plans for 


customer support: Basic Support, Express Support, and 24 X 7 Support. Both the Basic 
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Support and Express Support plans offer telephone service between 6:00 am to 5:00 pm, 


Pacific Standard Time, excluding holidays. 


e Basic Support: Includes unlimited support via telephone to assist the Remedy 
user with product installation and usage. Initial response times from the time of 
problem notification are not to exceed 24 hours. 


e Express Support: Includes same services as under Basic Support plan, but it 
guarantees initial response will not exceed four hours. 


e 7 X 24 Support: Includes around the clock support for mission critical users. 
b. Training 


Remedy offers a full range of training classes in two locations: Pleasanton, 
CA and Columbia, MD. Training covers all aspects of AR System and companion 
product design, installation, customization, administration, troubleshooting, and usage. 
[Ref. 23] An updated list of class descriptions, offering dates and costs is available at 
[http://www.remedy.com/training/index.htm]. In addition, Remedy also has a training 
option called Right to Teach where for one license fee, an individual attends one of 
Remedy’s training classes, receives training in instructing that course, and then is 
certified as an instructor. The license fee provides course materials and updates for one 
year with no limit on the number of students that may receive the training. Student 
workbooks, however, are priced separately. [Ref. 43] 

Cc Consulting 

Consulting services are available for help desk and other management 
functions. Services include: requirements analysis, system design, design review, system 
implementation, data migration, and custom Application Programming Interface (API) 
programming. [Ref. 23] An updated list of consulting services and prices is available at 


http://www.remedy.com/consulting. 
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4. Price 


Table 6.4 provides general price information. 


Table 6.4. Remedy Product Prices. [Ref. 43] 


PRODUCT PRICE | DESCRIPTION 


AR System Server, 3.0 w/MPSO- $9,500 Server and 3 fixed write licenses 
Windows NT 


AR System Client,3.0 
AR System Client, 3.0 | $10,000 | 5 floating licenses 


C. MIGRATION PATH ASSUMPTIONS 























l. Hardware/Software Purchase Requirements 
Table 6.5 shows the assumptions made as to whether components of the HOLIS 
LAN Architecture are pre-existing or must be purchased. 


Table 6.5. Target Architecture Purchase Requirements. 


1'LAN CATEGORY | COMPONENT PRE-EXISTING/MUST 
PURCHASE 


CT ~*Report Writers ——_~| Pre-existing 
Email —~*d Preexisting 
[Remote Notification | Must Purchase _———_—i| 
[NMS SS~*d Pre-existing ——S—C=~—~S 
—[—————— 






[| NMS Workstation | Pre-existing SSC 
Web Server ——S~*d Pre-existing ————SCSCSCSC~S 
-________ RSIMaail Server 
[Fite Server ————S—=*d Pre-existing SSCS 
application Server__[ Must Purchase 
a e 
Le 





Remote Access Ser 
Client Workstations _| Preexisting 
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a Users 


Table 6.6 displays assumptions made about the number of AR System, AR Web, 
Flashboards, Remote Notification (via alphanumeric pager), and Voice Recognition 
Software users. AR System users are sub-divided into fixed users, those who do not 
logout, and floating users, those who login occasionally to check status and then logout. 
The assumptions of 30 Total AR System users matches the scalability constraint in the 
problem formulation model. Pager users are assumed to be Department Head and 
Division Officer personnel. Voice Recognition software is used by Division Watch 


Supervisors. 


Table 6.6. Number of Users. 












FLOATING 
ARS USERS 


NCTAMS 30 
exstrac | | 
NCTAMS 20 | 
jar | 
NCTAMS Unlimited 
Pg eo 


5. Software Licenses Required 







TOTAL PAGER | VOICE 
FLASHBOARDS | USERS | RECOG 
USERS USERS 


cy 





Unlimited 









Unlimited — 






Table 6.7 shows the software licenses required to support the user mix shown in 
Table 6.6. Based upon discussion with the Remedy Federal Account Manager, the 
following Remedy license configuration is considered sufficient to support 10 fixed ARS 


users, 20 floating ARS users, unlimited AR Web users, and 10 Flashboards users. 
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Table 6.7. Remedy Product Licenses Required. [Ref. 56, Ref. 43, Ref. 42] 





~~ TUNIT | UNIT 
COST | COST 


ARS Server, 3.0 w/MPSO- Server and 3 fixed write | 1 $9,500 | $9,500 
Mase pelea ieee eee 
ARS Client, 3.0-Windows 5 fixed write Z $4,000 | $8,000 
ARWeb, 1.1, for Windows Server w/unlimited l $12,000 | $12,000 
ee ce es ok 
Flashboards Server, 1.2- Server and 5 fixed 1 $5,000 | $5,000 
Paes oe ee Te 


Flashboards Clients, 1.2- 5 fixed licenses $2,500 | $2,500 


Windows NT | | 
1 $1095 | $1095 


| LICENSE 





| PRODUCT 






















PPT EtherPage, 2.91 ~ | Per server with 8 pagers 


Kurzweil Voice for Windows $699 $6990 


4. Hardware/Software Compatibility 

Remedy WWW _- site  (http://www.remedy.com/CMATRIX/cmatrix.shtml) 
provides an updated list of combinations of computer platforms, operating systems, 
database software and protocol stacks which have been tested as compatible with ARS 
version 3.0. Table 6.8, 6.9, and 6.10 show the compatibility combinations that apply to 
this illustration. Regarding the database support, the reader is again reminded that time 
did not permit requirements analysis to determine which application best satisfies the 
problem formulation model. Both MS SQL Server, 6.5 and Oracle 7.3, Workgroup and 
Enterprise versions, comply with IT-21/Navy AIS standards as well as Remedy 
compatibility. The author chose to limit the illustration, however, to MS SQL for 


simplicity sake. 
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Table 6.8. AR System, Version 3.0 Server Compatibility Matrix. [Ref. 48] 


PLATFORM | OPERATING DATABASE MINIMUM 
SYSTEM SUPPORT REQUIREMENTS 


PC MS Windows NT MS SQL Server 6.5 32 MB Memory 
Compatibles Server, 4.0 20 MB Disk 


Table 6.9. AR System, Version 3.0 Client Compatibility Matrix. [Ref. 48] 





































a = = 
. 


MS Windows 


Table 6.10. Compatible TCP/IP Protocol Stacks. [Ref. 48] 


OPERATING SYSTEM TCP/AIP PROTOCOL STACK 
MS Windows, NT 4.0 MS TCP/IP Win 32 


= Customer Support 


OPERATING SYSTEM — 
MS Windows NT 4.0 


PLATFORM 
PC Compatibles 
e 386 processor 

e 16 Color VGA Display 
e 8 MB Memory (16 recommended) 
4 MB Disk 





Three customer support plans were introduced above: Basic Support, Express 
Support, and 7 X 24 Support. Based upon the availability and maintenance constraints of 
the problem formulation model, the author believes that 7 X 24 is the most appropriate 
support plan. 


6. System Administration 


The Target Systems DFD showed system administration/maintenance functions 
that will be part of the Target FMS Architecture. Traditionally, these functions are 
performed by a System Administrator. Since HOLIS also includes a DBMS, there are 
specific database design and maintenance functions that must be performed. The author 


envisions these duties divided between two people with one performing as System 
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Administrator and the other as Database Administrator (DBA)/Alternate System 
Administrator. Due to the relatively small size of the system, these would most likely not 
be full-time positions once the system was fully operational. During schema design, 
software installation, system configuration, and testing, System Administrator and 
Database Administrator would be full-time jobs. 

ee Training 

The author assumes that system implementation requires training for two types of 
users: System Administrator/DBA and general user. It is recommended that the System 
Administrator receive training throughout the system implementation process. The 
specific courses and stages at which these courses should be taken are detailed in the 
plateau options below. For the DBA, the amount of training required will vary depending 
based upon past experience. The author assumes that the DBA requires at least some MS 
SQL Server training. MS Course 750: Implementing a Database Design on Microsoft 
SQL Server 6.5 is one appropriate course; it is used in the migration path illustration 
below. Based upon the training constraint of the problem formulation model, it is 
recommended that the Right to Teach license option be utilized for general user training. 
One person would attend training at Remedy, receive instructional training, and return to 
the command to train the 30 system users. This would give the NCTAMS flexibility in 


terms of structuring and scheduling user training. 


i: MIGRATION PATH OVERVIEW 
I: Plateaus 
A plateau is described by the DOD SBA Planning Guide as stages in the journey 


from the baseline system to the target architecture; plateaus are designed to achieve 
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“clusters of business benefit”. [Ref. 10:p. 6-5] Figure 6.1 shows how achieving plateaus 
closes the gap between the Baseline System and Target Architecture. 

Plateaus between the Baseline FMS and the Target FMS, may be structured in 
numerous ways. For example, the Remedy Federal Account Manager recommends a 
phased approach where all three NCTAMS receive one portion of the system during the 
same time frame. Once implementation of the first portion is complete, each NCTAMS 
then receives the next portion. This cycle is repeated until system implementation is 
complete. [Ref. 7] While this approach has definite benefits in terms of full 
organizational commitment to system success, the author’s plateau design, described 
below, reflects her experience with system implementation ata NCTAMS. The timeline 


and cost estimates are purposely conservative. 


Target Architecture 


Plateau | 


Plateau II 


Viston 


System 
Baseline System ¥ 





Figure 6.1. Closing the “Gap” Between Baseline and Target 
Architectures. From [Ref. 10:p. 6-10]. 


119 


E Plateau I 


Plateau I implements the target architecture at NCTAMS EASTPAC. 
Pilot implementation at a single NCTAMS was chosen for two reasons: (1) To limit the 
risk associated with unsuccessful implementation (2) To gain requirements analysis, 
design, installation, training, and documentation lessons learned for later implementation. 
b. Plateau IT 
Plateau II implements the target architecture at NCTAMS LANT and 
NCTAMS MED. Both remaining NCTAMS were grouped into one final Plateau vice 
two, to benefit from economies of scale and shorten total implementation time. 
pa Phases 
Each plateau may be sub-divided into one or more phases. Initially, the tasks of 
Plateaus I and II] are assigned to one of three phases: A, B, or C which are described 
below. Where it was technically and operationally feasible, phases were combined or 
abbreviated to form other phase options. For example, Phase ABC contains all the tasks 
of Phases A, B, and C but requires a shorter amount of time to complete. Table 6.11 
shows the two options for achieving each Plateau and the phases which comprise these 
options. 


Table 6.11. Plateau Options. 


[PLATEAU [OPTIONS [A |B |C AA |BC_ [ABC | 
| Plateau | Opuonl.}l. | X X X 

pan tomenis |x PY Tf 
Plateau II Opuon II.1. x X 

pa tomoz | | PE 
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a Phase A 


Phase A is the first phase in Plateau I. It encompasses the implementation 
of the AR System and integration of e-mail and report writer software at NCTAMS 
EASTPAC. The estimated time to complete Phase A is 12 months. 

b. Phase AA 

Phase AA is the first phase in Plateau IJ. It encompasses the 
implementation of the AR System and integration of e-mail and report writer software at 
NCTAMS. LANT and NCTAMS MED. The estimated time to complete Phase AA is 
nine months. Although it is identical to Phase A, Phase AA is three months shorter, due 
to the implementation lessons learned during Plateau I, Phase A. 


C. Phase B 

Phase B is the second phase in Plateau I. It encompasses the 
implementation of AR Web and integration of NMS and remote notification software at 
NCTAMS EASTPAC. The estimated time to complete Phase B is six months. 

d. Phase C 

Phase C is the third phase in Plateau J. It encompasses the implementation 
of Flashboards and integration of voice recognition software at NCTAMS EASTPAC. 


The estimated time to complete Phase C 1s six months. 


e. Phase BC 


Phase BC is an alternate second phase in both Plateaus | and Il. It 
encompasses the events of Phases A and B. The estimated time to complete Phase BC 1s 


six months. Although Phase BC is essentially the same as Phases B and C, it is six 


12] 


months shorter, due to the economies of scale achieved by performing both phases at the 
same time. 
f Phase ABC 
Phase ABC is an option for Plateau II. It encompasses the events of 
Phases A, B, and C. The estimated time to complete Phase ABC is nine months; this 
compares to an estimated 24 months for Phases A, B, and C performed separately, 18 
months for Phases A and BC, or 15 months for Phase AA and BC. The significantly 
shorter time for Phase ABC 1s attributed to economies of scale by performing all phases 
at the same time. 
5. Migration Paths 
A migration path is a feasible path for moving from the baseline system to the 
target architecture. In the case of the NCTAMS FMS, Plateaus I and II must be achieved 
to reach the target architecture. As described in the previous Subsection, there are two 
options for achieving each Plateau. Combining these options, creates four possible 


migration paths shown in Table 6.12. 


Table 6.12. Migration Paths. 


[Migration Fash [TA— [12 [WL [12.[ Months To Complete 





Figure 6.2 shows migration path phasing. The estimated of length of each phase 
was described in Subsection 2, above. The rationale behind Option II.1. starting at the 18 
month point is to wait until completion of Phases A and B of Option 1.1. This means that 


the AR System and AR Web software would be operational at NCTAMS EASTPAC 
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prior to beginning implementation at NCTAMS LANT and MED. This would allow time 


for system feedback from fleet customers prior to further implementation. 


MIGRATION PATH PHASING 








PLATEAU | 


PLATEAU Il 


03 6 9 1215 18 21 24 27 30 33 36 
Months 


Figure 6.2. Migration Paths Phasing. 


BS. PLATEAU I 


Per discussion with Remedy Federal Account Manager, the options presented 
below represent feasible, albeit conservative, paths for achieving Plateau I. 


l. Option I.1. 


Table 6.13 displays Plateau I’s two options. Option I.1.phases are highlighted. 


2s 


Table 6.13. Option I.1. 


PHASES | EVENT 
Phase A Implement Internally to 12 months 
SS” |NCraMS EASTPAC 
Phase B Provide Customer Access Via | 6 months 
ne | sieve sae cl 
Phase C_ | Implement Management 6 months N 


T 
1.2. Phase A Implement Internally to N/A 12 months 
NCTAMS 
EASTPAC 
Phase BC } Provide Customer N/A 6 months 
Access Via SIPRNet & 
Implement Management 
Overview 


Tol [| SidtCSSSSSCSCSCSCSSSCS~*dS mots [TR OTS 


A. Description 










OPTION 1 |OPTION2 | 
IMELINE | TIMELINE 






N/A 
N/A 
/A 





The phases of Plateau I, Option I.1. may be described as follows: 


e PHASE A Description: 
e Implement ARS for use by 30 NCTAMS Classified LAN users. 
e Integrate e-mail and report writer software with ARS. 


e PHASE B Description: 


e Implement ARWeb for Customer/NCTS reporting, viewing of outage status 
and interaction with NCTAMS. 


e Integrate notification software and NMS with ARS and ARWeb. 


e PHASE C Description: 


e Implement Flashboards for real-time and historical monitoring of key 
processes, trend analysis, alert thresholds and user-configured alarms. 


e Integrate voice recognition software with ARS, ARWeb and Flashboards. 
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b. Timeline 
Timelines for Option I.1., Phases A, B, and C are displayed in Tables 6.14, 


6.15, and 6.16. 


Table 6.14. Phase A Overview (Option J.1.) 

















| ACTION [START | FINISH 
Requirements Analysis Remedy 


Procure System: NCTAMS Month 2 Month 5 
Hardware, Software, Training 

(Administrator), Installation & 

Maintenance 

Database Training -DBA Contracted Month 2 Month 2 


ARS Training - Administrator and Trainer 
Database Schema Design NCTAMS 
Hardware Installation NCTAMS 


Database Software Installation and NCTAMS Month 5 Month 5 
Configuration 


ARS Installation, Configuration and Remedy Month 7 
Integration NCTAMS 


i ee a sa ee 


Testing NCTAMS — ‘| Month 9 


NCTAMS 
[User Training | NCTAMS Month 1 
| Begin Operation NCTAMS Month 12 


| System Support Remedy Month 6 N/A | 
| as CLANS = | —— 


Table 6.15. Phase B Overview (Option I.1.) 


EVENT ACTION [START FINISH | 


Procure System: 


NCTAMS Month | Month 3 
Hardware, Software, Training 
(Administrator), & Maintenance a’ 
Advanced ARS Training - Remedy Month 2 Month 2 
ma. | 
ARWeb Installation, Configuration and | NCTAMS Month 3 Month 3 
Integration 































NCTAMS 
NCTAMS Month 4 
NCTAMS_[Month4 | Month3__| 
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Begin Operation NCTAMS 


System Support Remedy Month 3 N/A 
NCTAMS 


Table 6.16. Phase C Overview (Option I.1.) 


“ACTION [START | 


Procure System: NCTAMS Month 1 
Software, Training (Administrator), & 
Maintenance 


| 
+ lashboards Training - Administrator {Remedy | Month2 —=|Month2 | 


| Flashboards Installation, Configuration | NCTAMS Month 3 Month 3 
and Integration 


NCTAMS|Month4___| Month 


Documentation [NCTAMS a 


[User Training NCTAMS renee — 
[Begin Operation NCTAMS 


| System Support Remedy/ Month 3 
an NCTAMS 


Cc. Costs 









FINISH 
Month 3 


























Costs for Option I.1., Phases A, B, and C are displayed in Tables 6.17, 
6.18, and 6.19. Table 6.20 shows a one time customer support charge that 1s not 


associated with one particular phase but the option as a whole. 


Table 6.17. Phase A Costs (Option J.1.) 


EVENT | ITEM {UNIT  ~=—- | UNIT | ae tn 
COST COST | 


Requirements 

Analysis ] consultant $1,500/day | 5 days $7,500 

e Consultant 5 nights/6 days $1,500/trip | 1 trip $1,500 
[Ref.43] 

e Travel [Ref. 7] 


Hardware (Ref. 3} | Application Server $20,000 $20,000 


Software 
[Ref. 43] 













































ARS Server w/MPSO 
-NT 
ARS Chent - NT 

5 Fixed Licenses 


$9,500 | $9,500 















$4,000 
$10,000 


2 $8,000 
[1 $10,000 
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5 Floating Licenses 
(Ref. 26] $8,000 
MS SQL Server 6.5 
w/50 client licenses 


Training 
e Administrator 
[Ref. 43] Courses: 
1. ARS for Users & | $1,400 1 person $1,400 
Administering ARS 
from Windows 
(4days) $1,300 1 person $1,300 
2. Req. Analysis, 
Design & 
Development (3 days) | $2,550 ] trip $2,550 


) Trainer Travel: 13 nights/14 
| (Ref. 43] days $6,000 ] person $6,000 


| $500/10 (3) 10- $1,500 
| [Note 1] ARS for Users: Right | pack packs $1,050 
to Teach Course $1,050 1 trip 
e DBA Student Workbooks 
[Ref. 25] Travel: 3 nights/4 days Sie 7 5 
Sls 1 person 


MS Course 750: 

Implementing a 

Database Design on 

Microsoft SQL Server 

6.5 (5 days) 

Computer Training $10/day 
Academy Honolulu, 

HI 


Parking 
Installation 
e Consultant 1 consultant $1 .500/day 
[Ref. 43] 3 nights/4 days $1 .500/trip 
e Travel [Ref. 7] 
Customer Support 
[Ref. 43] 7 X 24 Option 23% of list | list price $6325 





price of total = 
licenses per | $27,500 
year 





fo 


Table 6.18. Phase B Costs (Option I.1.) 


ITEM UNIT ‘UNIT TOTAL | 
Pager Rental & $2 16/year $1,728/yr. 



















Hardware [Ref. 
41] 

























| Software 
(Ref. 43] AR Web, 1.1 $12,000 l $12,000 
[Ref. 42] EtherPage, 2.91 $1095 l $1,095 
Administrator | — 
Training ARS Advanced $1,700 







e Training [Ref. 
43] 














| 6 nights/7 days $1,500 





e Travel [Note 1] 
Customer Support | 
[Ref. 43] 






















23% of list 
price of 

licenses per 
year 


7 X 24 Option list price 
total = 


$12,000 





Table 6.19. Phase C Costs (Option I.1.) 


Flashboards 
Server, 1.2-NT $5,000 
Clients, 1.2-NT $2,500 


| [Ref. 56] Voice for Windows, $6,990 
ZU 
Training 


e Administrator Flashboards for 
[Ref. 43] Administrators (1 
day) 


[Note 1} 


Travel: 2 nights/3 
days 
e Trainer [Ref. 
43} Flashboards for 
Administrators- 
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Right to Teach iar 500 
days) 
Student Workbooks 


$1,050 


Travel: 3 nights/4 
days 
Customer Support 
(Ref. 43] PAB Hien 289/ctlieen Miswpniae 
price of total = 
licenses per | $7,500 
year 





Table 6.20. Option I.1. One Time Charge. 


EVENT ITEM UNIT UNIT TOTAL 
ee feose | [cost 
Customer Support | 7 X 24 Option - $20,000 1 $20,000 
fRerag]  |Oneumectage [Tf 
Note 1: Travel estimates calculated using the following rates: per diem 
rate for Alameda County, California of $111.00, rental car rate of $40.00 per day, and 
airfare from Honolulu, Hawaii to San Francisco, California of $600.00. All rates 


obtained from the Authorized Federal Travel Directory located at 
http://www. patsys.com/fid 










Zs Option I.2. 


Table 6.21 displays Plateau I options with Option 1.2. phases highlighted. 


Table 6.21. Plateau I, Option I.2. 


OPTION PHASES | EVENT OPTION 1 OPTION . 

RN [RSS ES [nneuine [TIL 
Phase A | Implement Internally to 12 months N/A 

ee ee ee 








Phase B Provide Customer Access 6 months 
Via SIPRNet 


Phase C | Implement Management 6 months | 
pT oreniow ee ee 
Phase A_ | Implement Internally to 12 months 
NCTAMS 









~ | Provide Customer 6 months 
Access Via SIPRNet & 
Implement Management 


Overview 
24 months | 18 months 





4. Description 
The phases of Plateau I, Option I.2. may be described as follows: 
e PHASE A Description: 
e Implement ARS for use by 30 NCTAMS Classified LAN users. 


e Integrate e-mail and report writer software with ARS. 


PHASE BC Description: 


e Implement ARWeb for Customer/NCTS reporting, viewing of outage status 
and interaction with NCTAMS. 


e Integrate pager software and NMS with ARS and ARWeb. 


e Implement Flashboards for real-time and historical monitoring of key 
processes, trend analysis, alert thresholds and user-configured alarms. 


e Integrate voice recognition software with ARS, AR Web and Flashboards. 


b. Timeline 


Timelines for Option 1.2., Phases A and BC are displayed in Tables 6.22 
and 6.23. 


Table 6.22. Phase A Overview (Option 1.2.) 


EVENT ACTION START | FINISH | 
Requirements Analysis 


Procure System: NCTAMS Month 2 Month 5 | 
Hardware, Software, Training (Administrator), 

Database Training -DBA Contracted | Month 2 Month 2 

Trainer 


Installation & Maintenance 
ARS Training - Administrator & Trainer 
Database Schema Design NCTAMS | Month3 | MonthS | 
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Month 5 
Month 5 


Hardware Installation : |NCTAMS | NCTAMS }Month5 | 5 


| Database Software Installation and NCTAMS Month 5 } 
| 
| ARS Installation, Configuration and Remedy Month 5 Month7 | 
fnegaion [crams | fn 


Integration 
NCTAMS 
NCTAMS Month 9 


User Training | Month9 | Month 11 


Begin Operation NCTAMS — | Month 12 


System Support Remedy Month 6 N/A 
NCTAMS 


Table 6.23. Phase BC Overview (Option I.2.) 


| EVENT 


Enhancement Review 
- Procure System: 


_ Hardware, Software, Training (Administrator), 


NCTAMS Month 1] Month 3 
| & Maintenance 


Training - Administrator and Trainer 


System Installation, Configuration and NCTAMS | Month4 | Month 4 
| Integration 


Testing ——SCSCSCSS_NCTAMSS 
[Documentation —~—SCSCS NT AMSS 
[User Training __———~—SCSCSCS NCTAMSS 
Begin Operation NCTAMS 


| System Support Remedy/ Month4 |N/A 
| NCTAMS ea. | 


Cc. Costs 


































FINISH | 



















Costs for Option I.2., Phases A and BC are displayed in Tables 6.24 and 
6.25. Table 6.26 shows a one lume customer support charge that 1s not associated with 


one partucular phase but the option as a whole. 
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Table 6.24. Phase A Costs (Option I.2.) 


EVENT. 


Requirements Analysis 
e Consultant [Ref.43] 
e Travel [Ref. 7] 

| Hardware [Ref. 3] 
Software _ 

[Ref. 43] 





[Ref. 26] 


Training 
e Administrator 
| [Ref. 43] 


{Note 1] 
e Trainer 
[Ref. 43] 


[Note 1] 


| 
| © DBA 
| {Ref. 25] 


installation 


e =6 Travel [Ref. 7} 
Customer Support 
{Ref. 43] 


e Consultant (Ref. 43] 


ITEM UNIT COST 


$1,500/day 
$1,500/trip 


1 consultant 





5 nights/6 days 


Application Server $20,000 















| ARS Server w/MPSO - NT 
| ARS Client - NT 

5 Fixed Licenses 

5 Floating Licenses 


$9,500 



























$4,000 
$10,000 





MS SQL Server 6.5 w/50 
client licenses 


Courses: 
1. ARS for Users & 

| Administering ARS from 
Windows (4days) 

| 2. Req. Analysis, Design & 

| Development (3 days) 


Travel: 13 nights/14 days $2,550 


ARS for Users: Right to 
Teach Course 

_ Student Workbooks 

| Travel: 3 nights/4 days 


| $500/10 pack | 
$1,050 


MS Course 750: 
implementing a Database 
Design on Microsoft SQL 
Server 6.5 (5 days) 
Computer Training Academy 
Honolulu, HI 


Parking $10/day 























! consultant 
3 nights’4 days 


$1,500/day 
$1.500/trip 


7 X 24 Option 23% of list 


price of 
licenses per 
year 


: 


UNIT 


5 days 
1 trip 
1 server 


| person 
| person 
| trip 

| person 
(3) 10- 


packs 
1 trip 


1 person 


5 days 


3 days 
1 trip 


list price 


total = 
$27,500 





TOTAL | 
COST | 


_ 


$7,500 
$1,500 


$20,000 


$9,500 


$8,000 
$10,000 


$8,000 





$1,400 

| $1,300 
$2,550 
$6,000 


$1,500 
$1,050 


$1775 


$50 


$4.500 
$1,500 


$6,325 


Table 6.25. Phase BC Costs (Option I.2.) 


Software 
| (Ref. 43] 


| (Ref. 42] 


(Ref. 43] 


[Ref. 56] 
Training 
e Administrator 
(Ref. 55] 


(Note 1] 


e Trainer 
(Ref. 43] 


AR Web, 1.1 
EtherPage, 2.91 
Flashboards 

Server, 1.2 - NI 

Client, 1.2. - NT 
Voice for Windows, 2.0 
ARS Advanced Topics (5 
days) 
Flashboards for 
Administrators (1 day) 


Travel: 9 nights/10 days 


Flashboards for 


~ | TOTAL COST 


$12,000 


| $1,095 


$5,000 
$2,500 


$699 


| $1,700 


'$ 400 


$1,950 


$6,000 


$1,728/yr. 


$12,000 


$1,095 


$5,000 
$2,500 


$6,990 


$1,700 


$ 400 


$1,950 


$6,000 


Administrators -Right To 

Teach (2 days) 

Student Workbooks $500/10 pack $1,500 
[Note 1] 

| Customer Support 


! [Ref. 43] 


Travel: 3 nights/4 days $1,050 $1,050 


7 X 24 Option 23% of list 
price of licenses 
per year 


list price | $4,485 


total = 





Table 6.26. Option I.2. One Time Charge. 









EVENT ITEM «| UNITCOST) =o [T UNIT” = | TOTAL COST} 
Customer Support 7 X 24 Option - One time | $20,000 $20,000 | 
[Ref. 44] charge , | 


Note 1: Travel estimates calculated using the following rates: per 
diem rate for Alameda County, Califorma of $111.00. rental car rate of $40.00 per day. 
and airfare from Honolulu. Hawaii to San Francisco, California of $600.00. All rates 
obtained from the Authorized Federal Travel Directory located at 
http://www.patsys.com/ftd 


es PLATEAU II 
li Option II.1. 


Table 6.27 displays Plateau II’s two options. Option II.1. phases are highlighted. 


Table 6.27. Plateau II, Option IL.1. 


OPTION PHASES OPTION 1 
Phase AA Implement Internally to NCTAMS 9 months 
PMO" Ure ncras Med 









OPTION2 
TIMELINE 






Phase BC Provide Customer Access Via 6 months 
SIPRNet & Implement Management 
Overview 





2: Phase ABC | Implement Internallyto NCTAMS |N/A 
LANT/MED & Provide Customer 
Access Via SIPRNet & Implement 
Management Overview 


roa SS ~*dCSSmioriths _[ ots 







a. Description 
The phases of Plateau II, Option II.1. may be described as follows: 
e PHASE AA Description: 


e Implement ARS for use by 30 Classified LAN users at NCTAMS LANT and 
30 Classified LAN users at NCTAMS MED. 


e Integrate e-mail and report writer software with ARS. 


e PHASE BC Description: 


e Implement AR Web for Customer/NCTS reporting, viewing of outage status 
and interaction with NCTAMS. 


e Integrate pager software and NMS with ARS and ARWeb. 


e Implement Flashboards for real-time and historical monitoring of key 
processes, trend analysis, alert thresholds and user-configured alarms. 


e Integrate voice recognition software with ARS, ARWeb and Flashboards. 


b. Timeline 


Timelines for Phases AA and BC are displayed in Tables 6.28 and 6.29. 
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Table 6.28. Phase AA Overview (Option II.1.) 
















EVENT ACTION START | FINISH 
Pre-Production Design Review 
N 


Procure System: CTAMS Month2 | Month 4 
Hardware, Software, Training (Administrator), | 
Installation & Maintenance 

Database Training - DBA Contracted Month 2 | Month 2 


ARS Training - Administrator and Trainer 
Hardware Installation NCTAMS 


Database Software Installation and NCTAMS Month 5 | Month 5 
ARS Installation, Configuration and Remedy Month 5 | Month 6 


Testing 
Documentation 
User Training 
Begin Operation 


System Support Remedy Month5 | N/A 
NCTAMS 


Table 6.29. Phase BC Overview (Option II.1.) 


PevENT TT ACHION [START [FINISH] 
| Procure System: NCTAMS Month 1 | Month 3 

Hardware, Software, Training (Administrator), , 
& Maintenance : 


Training - Administrator and Trainer ‘Remedy | Month2 | Month2_| 


| System Installation, Configuration and NCTAMS Month4 | Month4 {| 
Integration 


System Support Remedy Month4 | N/A 
NCTAMS 


c: Costs 









Costs for Phases AA and BC are displayed in Tables 6.30 and 6.31. The 


reader is advised that Plateau II] cost figures reflect implementation at a single NCTAMS. 
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These numbers will be doubled in the next chapter to reflect the total cost of 
implementation at both NCTAMS LANT and MED. Table 6.32 shows a one time 
customer support charge that is not associated with one particular phase but the option as 


a whole. 


Table 6.30. Phase AA Costs (Option II.1.) 


UNIT COST UNIT 








TOTAL | 
COST _ 


$4,500 





Pre-Production Design 
Review 

e Consultant [Ref. 43] 
|e Travel [Ref. 7} 
LANT 

MED 






















1 consultant 
3 nights/4 days 


$1,500/day 3 days 






















$1,500/trip 
$2,000/trip 


$1,500 
$2,000 


l trip 
] trip 






Hardware [Ref. 3] ARS Server $20,000 $20,000 
Software | 





















[Ref. 43] ARS Server w/MPSO- 
NT 
ARS Client-NT 

5 Fixed Licenses 


5 Floating Licenses 


| $9,500 $9,500 
















$4,000 
| $10,000 


$8,000 
$10,000 















[Ref. 26] MS SQL Server 6.5 


w/50 Client Licenses 


$8,000 $8,000 
Training 
|e Administrator Courses: 
| Ref. 43] |. ARS for Users & $1,400 1 person 
Administering ARS 
| from Windows 
| (4days) $1,300 1 person 
: 2. Req. Analysis, 
Design & 
Development (3 
days) 
[Note 2] $2,220 1 trip 
Travel: 
LANT Travel (12 $3,040 | trip 
nights/I13 days) 
MED Travel (14 
nights/15 days) 


$1,400 


$1,300 


$2,220 


$3,040 


e Trainer $6,000 | person 
(Ref. 43} ARS for Users: Right 
to Teach Course $500/10 pack (3) 10-packs 
Student Workbooks 
| [Note 2] 
: Travel: $520 ] trip 


° DBA 
[Ref. 25] 


| Installation 

ie Consultant [Ref. 43] 
e Travel [Ref. 7] 
LANT 

| MED 
Customer Support 

| (Ref. 43] 





7 X 24 Option 23% of list 
price of licenses 
per year 


LANT Travel (2 

nights/3 days) ; | trip 
MED Travel (4 

nights/5 days) 


] person 

MS Course 750: 
Implementing a 
Database Design on 
Microsoft SQL Server 
6.5 (5 days) 
Ameridata Learning 
Norfolk, VA 

$50 
LANT: Parking $2,020 
MED: Travel (8 
nights/9 days) 


] consultant 
3 nights/4 days 


list price total 
= $27,500 


Table 6.31. Phase BC Costs (Option IT.1.) 






Software 
[Ref. 43] 





(Ref. 42] 


(Ref 43] 







[Ref 56] 













Training 
e Administrator 
[Ref 43] 


EVENT ITEM ‘TITEM ~—._ | UNITCOST [UNIT 
Hardware [Ref. 41] Pager Rental & $2 16/year 
re =} 
















| TOTAL | 






$1,728/yr. 






AR Web,1.1 


EtherPage, 2.9] 





Flashboards 
Server, |.2-NT 
Client, 1.2-NT 


Voice for Windows, 
20 








| trip 
] trip 





ARS Advanced Topics 
(S days) 

Flashboards for 
Administrators (1 day) 


LANT Travel: 8 
nights/9 days 
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| MED Travel: 10 
nights/11 days 


e Trainer Flashboards for $6,000 $6,000 
[Ref. 43] Administrators -Right 

To Teach (2 days) 

Student Workbooks $500/10 pack $1,500 


[Note 2] LANT Travel: 2 | 
nights/3 days | $520 $520 
MED Travel: 4 $1,280 $1,280 
nights/S days | 


Customer Support 

[Ref. 43] 7 X 24 Option 23% of list list price total | $2,001 
price of licenses | = $8,700 
per year 





Table 6.32. Option II.1. One Time Charge. 


EVENT ITEM UNIT COST UNIT TOTAL 
COST 





Customer Support 7 X 24 Option - One $20,000 $20,000 
[Ref. 62] time charge 


Note 2: Travel estimates calculated using the following rates: per 
diem rate for Columbia, Maryland of $130.00 and Norfolk, Virginia of $130.00, rental 
car rate of $40.00 per day, and airfare from Norfolk, Virginia to Baltimore/Washington 
International (BWI) Airport of $180.00 and from Naples, Italy to BWI Airport of 
$660.00. All rates obtained from the Authorized Federal Travel Directory located at 
http://www. patsys.com/ftd 


2. Option II.2. 


Table 6.33 displays Plateau II’s two options. Option II.2. phases are highlighted. 
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Table 6.33. Plateau II, Option II.2. 

















OPTION EVENT OPTION | OPTION 2 
TIMELINE 
Phase AA Implement Internally to NCTAMS LANT | 9 months N/A 
pee [akctavswe NT [Pons 
Phase BC Provide Customer Access Via SIPRNet & | 6 months N/A 
— | Implement Management Overview — 4 
die? 
Total | 





Phase ABC | Implement Internally to NCTAMS N/A 9 months 
LANT/MED & Provide Customer Access 
Via SIPRNet & Implement Management 
Overview 


Tol dS ES months _ | mo 


a. Description 
The phases of Plateau II, Option IJ.2. may be described as follows: 
e PHASE ABC Description: 


e Implement ARS for use by 30 NCTAMS LANT and 30 NCTAMS MED 
Classified LAN users. 


e Integrate e-mail and report writer software with ARS. 


e Implement ARWeb for Customer/NCTS reporting, viewing of outage status 
and interaction with NCTAMS. 


e Integrate pager software and NMS with ARS and ARWeb. 


e Implement Flashboards for real-time and historical monitoring of key 
processes, trend analysis, alert thresholds and user-configured alarms. 


e Integrate voice recognition software with ARS, ARWeb and Flashboards. 


b. Timeline 


The timeline of Plateau II, Option II.2. are displayed in Tables 6.34: 
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Table 6.34. Phase ABC Overview (Option II.2.) 


EVENT — ACTION | START | FINISH | 
Pre-Production Design Review 


Procure System: IMSC Month 2 | Month 4 
Hardware, Software, Training 
| (Administrator), Installation & 
Maintenance 
Database Training -DBA Contracted Month2 | Month 2 


ARS Training - Administrator and Trainer 
Database Schema Modification IMSC 
Hardware Installation IMSC Month 5 


| Month 5 
Database Software Installation and IMSC Month 5 Month 5 
Configuration 


Begin Operation 
N/A 


System Support /Month6 — 
The costs of Plateau II, Option II.2. are displayed in Table 6.35. Table 

























= - = la 8 


Cc. Costs 


6.36 shows a one time customer support charge that is not associated with one particular 
phase but the option as a whole. 


Table 6.35. Phase ABC Costs (Option II.2.) 


COST | 


Pre-Production Design 
Review 
e Consultant [Ref. 43] | ! consultant $1,500/day 
e §=6Travel [Ref. 7] 
LANT 3 nights/4 days $1,500 
MED 5 nights’6 days $2,000 


Hardware [Ref. 3] ARS Server $20,000 | server $20,000 
Pager Rental & Service $216/year 8 $1,728/yr. 


Software | 
| (Ref. 43) ARS Server wW/MPSO-NT | $9,500 $9,500 | 
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[Ref. 26] 


[Ref. 43] 
[Ref. 42] 


(Ref. 43] 


[Ref. 56] 
Training 


e Administrator 
[Ref. 43] 


| (Note 2] 


e Trainer 
{Ref 43] 


[Note 2] 


| (Ref. 43] 


ARS Client-NT 
5 Fixed Licenses 
5 Floating Licenses 


MS SQL Server 6.5 w/50 
licenses 


AR Web, 1.1 
EtherPage, 2.91 


Flashboards 
Server, 1.2-NT 
Clients, 1.2-NT 


Voice for Windows 


Courses: 

1. ARS for Users & 
Administering ARS from 
Windows (4days) 

2. Req. Analysis, Design 
& Development (3 days) 


Travel: 

LANT Travel (12 
nights/13 days) 

MED Travel (14 nights/15 
days) 


ARS Advanced Topics (5 
days) 

Flashboards for 
Administrators (1 day) 


LANT Travel: 8 nights/9 
days 

MED Travel: 10 nights/1} 
days 


ARS for Users: Right to 
Teach Course 
Student Workbooks 


Travel 

LANT Travel (2 nights’3 
days) 

MED Travel (4 nights/5 
days) 


Flashboards for 


14] 


$4,000 
$10,000 


$8,000 
$12,000 
$1,095 
$5,000 
$2,500 


$699 


] person 


] person 


$2,220 1 trip 


$3,040 


$1,700 


$ 400 


$1,540 


$2,300 


$6,000 


$500/10 pack 


$520 


$1,340 


$6,000 


$8,000 
$10,000 


$8,000 
$12,000 
$1,095 
$5,000 
$2,500 


$6,990 


$1,400 


$1,300 


$2,220 


$3,040 


$1,700 


$ 400 


$1,540 


$2,300 





Administrators -Right To 
Teach (2 days) 
Student Workbooks $500/10 pack 


[Note 2] LANT Travel: 2 nights/3 $520 
days 
MED Travel: 4 nights/5 $1,280 
days 


e DBA MS Course 750: $1,774 1 person $1,775 
(Ref. 26] Implementing a Database | 

Design on Microsoft SQL 

Server 6.5 (5 days) 

Ameridata Learming 

Norfolk, VA 


LANT: Parking $10/day 
MED: Travel (8 nights/9 52,020 
days) 


Installation 
e Consultant [Ref. 43] | | consultant $1,500 | $4,500 
|e Travel [Ref. 7] | (3 nights/4 days) | 
LANT $1,500 $1,500 
MED $2,000 $2,000 
Customer Support 
| (Ref. 43] 7 X 24 Option 23% of list list price $10,810 
! price of total = 
licenses per $47,000 
year 





Table 6.36. Option I.2. One Time Charge. 


|; EVENT ITEM y UNIT COST _ TOTAL | 
Customer Support 7 X 24 Option - One time $20,000 $20,000 
Se ES ep 


Note 2 : Travel estimates calculated using the following rates: per 
diem rate for Columbia, Maryland of $130.00 and Norfolk, Virginia of $130.00, rental 
car rate of $40.00 per day, and airfare from Norfolk, Virginia to Baltimore’/Washington 
International (BW1) Airport of $180.00 and from Naples, Italy to BWI Airport of 
$660.00. All rates obtained from the Authorized Federal Travel Directory located at 
http://www.patsys.com/ftd 









142 


G. SUMMARY 

This chapter produced four feasible migration paths and outlined the timelines 
and cost breakdowns associated with each one. With these paths established, the next 
chapter will select the best course to transition from the Baseline FMS to the Target 
HOLIS architecture using the criterion and constraints of the problem formulation model 


developed in Chapter V. 
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VII. SELECTING A MIGRATION PATH 


A. INTRODUCTION 

The sixth step of the TAFIM process is Selecting the Migration Path. In Chapter 
Six, four migration paths were developed that meet the constraints of the problem 
formulation model. In this chapter, one migration path will be selected that best satisfies 


the objective of minimizing system cost. 


B. MIGRATION PATH SELECTION 

1. Methodology 

The objective of the problem formulation model is to minimize cost over the 
system lifecycle. Therefore, according to the model criterion, the migration path with the 
lowest lifecycle cost is the best choice. The Net Present Value (NPV) technique is used 
to calculate the present value of system costs estimated in Chapter Six. A standard 
discount rate of 10 percent is used throughout the calculations. Additionally, since post- 
implementation costs will be the same for each of the four migration paths, only the 
system costs during the three year implementation period will be used for path selection. 

re Cost Calculation 

Tables 7.1 through 7.4 below, were created using the following technique: (1) 
Cost estimates for phases were summed to calculate a cost for each migration path option 
(1.1. 1.2. UL... and 1.2); (2) Migration path option costs were categorized as occurring 
during year zero (0-12 months), year one (135-24 months), or year two (25-36 months); 
(3) Categorized migration path option costs were combined to create migration path 


costs, ¢.g.. migration path one is comprised of options I.1 and I].1. The One Time Fee of 
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$20K shown in each year for the four migration paths is part of the Remedy customer 
support fee ($20K plus 23 percent of the application price). The $20K is shown 
separately, because it can not be attributed to any one particular phase. 

A. Migration Path One 

Table 7.1 shows the NPV cost of Migration Path One which is comprised 
of Options I.1 and II.1. Phase A costs reflect implementation during the first 12 months 
with customer support in Years One and Two. Phases B, C, and AA costs reflect 
implementation during Year One with customer support in Year Two. Phase BC costs 
reflect implementation in Year Two. Using a discount rate of 10 percent, the NPV of 
total cost for Migration Path One is $568,448. 


Table 7.1. Migration Path One NPV Calculation. 


IMIGRATION PATH 1-OPTIONS 1.1 & 
11.4 


Po 0:(0-12 mo) Yr 1:(13-24 mos) [Yr 2:(25-36 mos) 















92,450, —=«6,325| «i325 
I a aa 20,783, ~~, 760 
PhaseC | CY SSCSC~«OHS|CSCT 
Phase AA | ott, 790[ 12,650 
PhaseBC_———sd|—SC~CS~—S OT SCSC~CS~S~S~SSC“‘“‘*«wS:«CB 


One Time Fee 60,000 60,000 60,000 
Totals $152,450 $294,963 $149,328 
Ps | 


| Lae 
INPV (@10%) = (152,450)(1/(1+.1")) + (294,963)(1/(1+.1)) + 


(149,328)(1/(1+.17)) 
a” 


$152,450 + $268,148 + $147,850 = $568,448 





b. Migration Path Two 


Table 7.2 shows the NPV cost of Migration Path Two which is comprised 
of Options I.1 and II.2. Phase A costs reflect implementation during the first 12 months 


with customer support in Years One and Two. Phases B, C, and ABC costs reflect 
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implementation during Year One with customer support in Year Two. Using a discount 
rate of 10 percent, the NPV of total cost for Migration Path Two is $595,982. 


Table 7.2. Migration Path Two NPV Calculation. 


IMIGRATION PATH 2-OPTIONS I.1 & 
1.2 
Yr 0:(0-12 mos) [Yr 1:(13-24 mos) |Yr 2:(25-36 mos) 

Phase A 6,325) 
[Phase B 2,760 

hase C 

hase ABC 
One Time Fee 
Totals 


NPV (@10%) = (152,450)(1/(1+.1°)) + (387,219)(1/(1+.1")) + (92,430)(1/(1+.17)) 


$152,450 + $352,017 + $91,515 = $595,982 


Cc. Migration Path Three 





Table 7.3 shows the NPV cost of Migration Path Three which is 
comprised of Options I.2 and II.1. Phase A costs reflect implementation during the first 
12 months with customer support in Years One and Two. Phases BC and AA costs 
reflect implementation during Year One with customer support in Year Two. Phase BC 
costs reflect implementation in Year Two. Using a discount rate of 10 percent, the NPV 


of total cost for Migration Path Three is $568,039. 
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Table 7.3. Migration Path Three NPV Calculation. 





MIGRATION PATH 3-OPTIONS 1.2& | 










(1.1 

Pd 00-12 mos) [Vr 1:(13-24 mos) 
PhaseBC——SidYSSCSC*~YSC‘“‘CC™C#O«SORY™ON#*#*‘«d 485 
PhaseAA «dT —SSSSCS~YSCSC*~*~«BTSOY~C~*«d« 5 
PhaseBC_——S«d|——SsCSC~C~C~S~SSSC<C~*~*~‘~*~*~SC‘“‘“‘;*wS:«CBC 
$149,328 
Tt = lalla ela 


NPV (@10%) = (152,450)(1/(1+.1")) + (294,513)(1/(1+.1)) + 
(149,328)(1/(1+.17)) 
$152,450 + $267,739 + $147,850 = $568,039 


d. Migration Path Four 

Table 7.4 shows the NPV cost of Migration Path Four which is comprised 
of Options I.2 and II.2. Phase A costs reflect implementation during the first 12 months 
with customer support in Years One and Two. Phases BC and ABC costs reflect 
implementation during Year One with customer support in Year Two. Using a discount 
rate of 10 percent, the NPV of total cost for Migration Path four is $595,573. 


Table 7.4. Migration Path Four NPV Calculation. 


MIGRATION PATH COPTIONS 12 
H.2 eee 


P______]¥r 0:(0-42 mos) |¥r 1:(13-24 mos) |¥r 2:(25-36 mos)| 
PhaseA————~YC~<CS~*é‘~éABOL:SCOC™*‘“‘C#‘COWS2OW™”CO™*«*«éi«;«S 
PhaseBC ——s~dY—SC~CS~Ss=~—SSC“‘S«#S«O#!™SO#*#*‘*«A« ABS 
PhaseABC ———~«|——S™~S~—SSCSC~*~iH«OG]_—~C~C~*«C«O 
One Time Fee —+| 60,000 60,000] 60,000] 
Totals —~—~S*=~«~C*é‘“~;*~*ésS AS 2, —~=~C*‘“‘“‘&‘G, 769) —_—~$ 92,430 
Cee ae 


pinnate 
NPV (@10%) = (152,450)(1/(1+.1")) + (386,769)(1/(1+.1")) + (92,430)(1/(1+.1-)) 
$152,450 + $386,769 + $92,430 = $595,573 
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3; Path Selection 

Table 7.5 summarizes migration path costs and number of months to implement. 
Migration Path Three is the optimal choice based upon the problem formulation model 
objective to minimize cost. It is worth noting, however, the closeness of all four 
migration path totals. There is a $409 difference between the two least costly paths, One 
and Three, and a $27,943 delta between the highest and lowest cost paths, Two and 
Three. In the author’s opinion, this small price differential is relatively insignificant 
when compared with the total system cost. Secondary concerns such as, number of 
months to implement (e.g., 33 months for Paths One and Three, 27 months for Paths Two 
and Four) and option phasing to maximize organizational acceptance, will mostly likely 
take on a greater role in the migration path selection process due the small range in costs. 


Table 7.5. Migration Path Summary. 


MIGRATION PATH 





nr} — 
eee 
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VIII. RECOMMENDATIONS AND CONCLUSIONS 


A. CONCLUSIONS 

The role of the JFTOC will continue to grow in scope and complexity as 
information technology takes on an increasingly central role in achieving the vision of 
DOD expressed in JV 20/0. As the manager of NCTC services in each geographic 
region, the NCTAMS can no longer rely on a non-networked, primarily manual FMS to 
administer. these network-centric resources. To do so, would, in the author’s opinion, 
either require additional personnel to maintain the same quality of service or result in a 
service quality decrease; neither of which are an option in the current operational and 
fiscal environment. This study illustrated how the TAFIM model is used to define the 
system problem using a formulation model, document the baseline system, develop a 
target architecture and migration paths to achieve it, and select a path based upon the 
criteria and constraints of the formulation model. 

Although the Target FMS and Migration Paths may differ depending upon the 
membership and experience of the process design team, this study 1s a valid illustration of 


the TAFIM approach. and the FMS architecture provides the following benefits: 


e DISN usage (SIPRNet) 
e {T-2] Minimum AIS Standards compliant. including: 
e Use of existing IT-21 compliant LAN 


e Use of existing and additional IT-2] compliant software, including: NOS, 
Office Automation, E-mail. and Relational DBMS. 


e Use of existing and additional IT-21] servers. 
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e Single PC concept (employed workstation used for multiple tasks) 
e COTS product usage 

e Client/server architecture 

e Secure through DISN usage and access control at user level 


e Interoperable between NCTAMS due to software and database design 
commonality, compatibility, and standardization. 


e Scalable from tens to thousands of users 
e Integrateable with Third Party Applications 
e Customizable GUI via point-and-click 


e Minimal user training required 


B. RECOMMENDATIONS 
hes Use of Modified Structured Approach 


A structured approach is one that uses the traditional Systems Development Life 
Cycle (SDLC) methodology with its various project phases such as planning, analysis, 
design, implementation, and maintenance. [Ref. 17] With the HOLIS architecture, the 
author recommends using a modified structured approach which is markedly streamlined 
due to the use of COTS products. Appendix C provides a management overview 
template for using a modified structured approach for the HOLIS project. Items labeled 
as “Not Covered in Thesis, Required” are necessary steps, but due to time constraints, 
were not addressed by this thesis. Those items labeled “Review and Update” were 
presented in this thesis and this discussion may serve as a Starting point for team review. 
Items labeled as “Not Required - COTS” are those steps that were eliminated due to 


COTS employment. 
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De Use of a Multi-Disciplined Project Team 

It is essential that HOLIS project benefit from the use of a team of diverse 
membership. The purpose of this team is to provide management and oversight, as well 
as to decide which project phases will be performed directly by the group and which will 
be delegated or outsourced. As such, the team must include a mixture of corporate and 
technical experts. Members should bring both the managerial and operational 
perspectives to the project. In addition, the team needs a champion, a senior leader who 
is committed to the project and will promote and guide the project. [Ref. 17:pp. 98-99} 
The use of an integrated team from all three NCTAMS will greatly simplify the process 
of attaining interoperability through use of standardized database schemas, business rules, 
and other procedures. 

ae Use of a Phased Implementation Approach 

The project team will decide the best method of implementation through its 
migration path design. The author strongly believes, however. that implementation must 
use a phased approach. Specifically, regardless of whether the system is implemented 
using the plateaus and phases outlined in Chapter Six, implementation of the entire 
system (i.e. Remedy AR System/ARWeb/Flashboards and other applications which 
integrate with Remedy) should not occur at the same time. A phased approach 1s 
preferred, because the author believes that each NCTAMS needs time to accept and 
become proficient with the system before allowing customers and external stakeholders 
(e.g., staff members from Fleet CINCs. Numbered Fleet Commanders. and NCTC) to 


access the system to check a status or perform a query. 
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4. Integration of Measures of Performance (MOPs) and Measures of 
Effectiveness (MOEs) 


Measures of quality are included in performance monitoring rather 
than being segregated in a class by themselves because high-quality 
operations can only be achieved when measurement and improvement of 


quality is an integral part of the work process, rather than being something 
attached as an afterthought. [Ref. 17:p. 117] 


This quote from Hoffman about integrating MOPs and MOEs into business 
processes is important to the HOLIS project for two reasons. First, the Information 
Technology Reform Act (ITMRA) of 1996 requires federal agencies to establish metrics 
to eeeeure the performance of IT investments. Therefore, MOEs and MOPs are legally 
required for HOLIS. Second, in keeping with the Hoffman quote, NCTAMS 
telecommunications professionals, striving for continous improvement of the information 
services they provide, need a way to measure the quality of those services. [Ref. 17:p. 
117] MOPs provide a way to measure information system performance, while MOEs 
measure organizational performance. [Ref. 19] Recommendations for appropriate MOEs 
and MOPs should be made by the project team to senior leadership for approval. 

>. Emphasis on the Role of the aia and Database Administrator 

The importance of the System and Database Administrators roles can not be 
overemphasized. Successful performance of functions such as: configuring the database 
schemas, configuring the user interface, incorporating business rules, determining access 
permissions for new users, and performing daily system backups is critical to the 


system's success. 
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C. AREAS REQUIRING ADDITIONAL STUDY 

ly Integration of IMSCs Into HOLIS Architecture 

As the functions and tasks of the IMSCs become defined, their integration into the 
HOLIS Architecture will also have to be examined. For example, should fault 
information be stored centrally at the NCTAMS or distributed locally at the IMSCs? The 
answer to this question will determine whether the IMSCs require their own FMS or they 
submit trouble tickets to their regional NCTAMS via SIPRNet Web page. 

De Extension of FMS To Include Configuration and Asset Management 

Due to inherent time constraints, this research focused on only one aspect of the 
network management services performed by the JFTOC, fault management. However, 
“allocation and management of regional assets in support of Joint and Fleet 
Commanders,” a statement from the JFTOC mission, involves two other types of network 
management: asset and configuration management. An example of asset management 
performed by the JFTOC is tracking the number of UHF transceivers and their current 
employment. If one transceiver malfunctions, asset management allows informed and 
timely restoral decisions. Asset management is currently performed by the JFTOC using 
the Tactical Memo (TACMEMO); a flat file that is updated once a day to reflect the 
employment of NCTAMS controlled assets. An example of configuration management is 
loading a new version of software on message processing computers. Currently, 
configuration management 1s performed largely by the Electronic Maintenance 
Department (N6). 

The author recommends that these network management functions, fault, asset. 


and configuration, be viewed as interdependent. since a fault can generate a requirement 
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to change the use of assets or their configuration. The requirements analysis must 
include the processes performed under each type of network management. Help Desk 
applications such as Remedy have asset and change management modules that may be 


added to their core product. 


D. THESIS SUMMARY 


‘“ An organization can get the maximum benefit from the talents and energies of 
its workers only if each worker has the right information at the right time.” [Ref. 17:p. 
110] This quote from Hoffman best describes the motivation behind this thesis. Too 
often, due to the manual nature of the current FMS, the JWO is the only person close to 
having a complete picture of all outages. The inherent inefficiencies of this system waste 
the time, energy and contributions of the skilled operators who ensure continuity of 
information services. If all members of the Fleet Unit-NCTAMS team had the same 
near-real time picture and the ability to monitor their performance using metrics, the 


Navy get the maximum benefit from its information services professionals. 
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APPENDIX A. GUIDE TO DATA FLOW DIAGRAMS 


Introduction: 
Data Flow Diagrams (DFD) are a structured analysis technique used to show the 
processes that data undergo in a system. They use a series of symbols as a graphical 


representation of data movement, transformation, and storage. [Ref. 37, p. 229] 


Basic Symbols: 


Four basic symbols are used in DFD. Figure Al.1 shows the symbols, their meaning, and 


examples. 


SYMBOLS MEANING EXAMPLES 


7 Customer! 
TO] oe 
—__ > Data Flow Orderwre Entry 


7 — 


—= — 





Figure Al.l. DFD Symbols, Meaning, and Examples. 
After Ref. [37, p. 231] 


External Entity - External entities send or receive data from the system. An external 


entity is also called a data source or sink. Although 11 interacts with the system, it is 
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considered external to that system’s boundaries. External entities use noun names, e.g., 
Customer, and may be redrawn in several places on a diagram to avoid data flow lines 
from crossing. When shown more than once, the symbol is shown with a hash mark in 


the lower right hand corner. [Ref. 37, pp. 230-231] 


Data Flow - Data flows show movement of data from one point to another. The head of 
the arrow points toward the data destination. Data flows are also named using nouns, 


eg, COMsSPOl Dataz (Rem a7ip. 2315 


Process - Processes represent work being performed within the system that change or 
transform data. They are identified as either verbs or objects e.g., Log Outage. Process 
name specificity depends upon the level of the detail portrayed in the DFD. [Ref. 37, p. 
231} All data flows must either originate or terminate at a process, and each process 


must have at least one input and one output data flow. [Ref. 37, p. 238] 


Data Store - Data Stores represent depositories of data that allow input and retrieval of 
data. They may represent manual (e.g., filing cabinet) or automated (e.g., data base0 
Storage systems. Data Stores are named using nouns (e.g., COMSPOT Folder) and given 


a unique reference number such as D1, D2, D3 and so on. [Ref. 37, p. 232] 
Unique Symbols - In addition to the four standard DFD conventions described above, the 


author also uses the symbol shown in Figure A1.2 to indicate the data flow(s) that 


lriggers, inillates or drives each process. This is the process control element. 
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SYMBOL MEANING EXAMPLE 


DOR Request 


or Control o> 





Figure A1.2. Control Element Symbol, Meaning, and 
Example. 


Methodology: 


DFD are developed using a top-down approach. The first diagram drawn is the most 
general with succeeding diagrams including more and more detail; this technique is 


called diagram explosion. Types of DFD include: 


Context Level - The Context Level Diagram provides a “bird’s-eye view of data 
movement.” [Ref. 37, p. 232] It includes basic inputs, the general system, and basic 


outputs. The diagram does not include any data stores. [Ref. 37, p. 232] 


Level Zero - The Level Zero Diagram represents an explosion of the Context Level. It 
shows the data flows between each process and associated external entities and data 


stores. Each process ts labeled as an integer, e.g., Process 3. [Ref. 37, p. 233] 


Level One - A Level One Diagram shows one of the processes of the Level Zero in 
greater detail. This DFD is considered a child diagram of Level Zero. Level One 
processes are labeled using a scheme that takes the integer assigned to a process in a 
Level Zero Diagram, e.g., Process 3, and adds a decimal point and second integer, e.g.. 


Processes 3.1, 3.2, 3.3 and so on. [Ref. 37, p. 235] 
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Further Child Diagrams - The number of levels required to describe a process depends 
upon the system’s complexity. 
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APPENDIX B. MODIFIED STRUCTURED APPROACH 


I. SYSTEMS DEVELOPMENT MANAGEMENT 
¢ Planning (Review and Update) 
¢ Defining Project Scope 
¢ Establishing 
¢ Measures Of Performance (Information System Performance) 
¢ Measures of Effectiveness (Organizational Performance) 
¢ Scheduling 
¢ Budgeting 
¢ Senior Management Support 
¢ Organizing (Required) 
¢ Staffing Systems Development Team 
¢ Outsource vs. In-house 
@ Work Assignment 
¢ Establishing Lines of Communication 
¢ Controlling (Required) 
@ Progress Reports 
¢ Planned vs. Actual Accomplishment 
¢ Leading (Required) 


Il. SYSTEMS ANALYSIS 

¢ Major Problems Identified (Review and Update) 
¢ User Requirements (Review and Update) 

¢ Recommendations (Review and Update) 


II. GENERAL (CONCEPTUAL) SYSTEMS DESIGN 
@ Structure-Oriented Design Approach 
@ Process-Oriented Approach 
@ Data Flow Diagram (DFD) (Review and Update) 
¢ Entity Relationship Diagram (ERD) (Required) 
@ Structure Chart (Not Required - COTS) 
Process Specifications (Not Required - COTS) 


IV. SYSTEMS EVALUATION AND SELECTION 

@ Identification of COTS products that meet Formal Problem Definition (Review and 
Update) 

@ Identification of Decision Criteria (Review and Update) 

@ Selection of COTS product (Required) 


V. DETAILED (FUNCTIONAL) SYSTEMS DESIGN 
@ Output Design 
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@ Reports (Required) 
¢ Output Screens (Required) 
¢ Input Design 
¢ Input Screens (Required) 
¢ Database Design - Relational Model (Required) 
¢ Model entities and map to tables. 
¢ Designate primary keys 
¢ Model relationships between tables 
¢ Model attributes of tables 
@ Normalize database model 
Prepare data dictionary 
¢ Controls Design 
@ Input Controls (Provided - COTS) 
¢ Computer Security 
¢ Access Controls (Provided - COTS) 
@ Malicious Software Controls (Required) 
¢ Transmission Controls/Encryption (Provided - SIPRNet) 
¢ Physical Controls (Provided - Open Storage Secret Facility) 
¢ Environmental Controls (Required) 
¢ Back-up and Recovery Plans (Required) 
¢ Network Requirements (Review and Update) 
¢ Hardware Requirements (Review and Update) 
¢ Software Requirements (Review and Update) 


VI. SYSTEMS IMPLEMENTATION 
¢ Software Development (Proprietary Information - COTS) 
¢ Software designing 
@ Software coding 
Software testing 
@ Site Survey (Required) 
@ Equipment Installation (Required) 
¢ Testing (Required) 
¢ Training (Review and Update) 
@ Document Preparation 
@ Systems documentation 
COTS Products Documentation (Proprietary Information - COTS) 
Database Design (Required) 
Code Written to Link COTS Products (Required) 
@ Software documentation (Not required - COTS) 
@ Operations documentation (Provided - COTS) 
@ User documentation 
Users Manual (Provided - COTS) 
SOPS (Required) 
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¢ Conversion Strategy (Review and Update) 
¢ Pilot Conversion/Phased Approach 
¢ Post-Implementation Review (Required) 


VII. SYSTEMS MAINTENANCE (Required) 
¢ Corrective Maintenance 

¢ Adaptive Maintenance 

¢ Preventive Maintenance 


[Ref. 22] 
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